Bug 139376

Summary: Repeated warnings in dmesg about lost ticks
Product: [Fedora] Fedora Reporter: Parag Warudkar <parag.lkml>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED CANTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: pfrields, wtogami, zafar_mahmood
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-18 05:15:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/proc/cpuinfo
none
/proc/interrupts
none
lsmod output none

Description Parag Warudkar 2004-11-15 17:34:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko)

Description of problem:
I get repeated warnings about losing too many ticks in dmesg -

warning: many lost ticks.
Losing some ticks... checking if CPU frequency changed.
Your time source seems to be instable or some driver is hogging interupts.

Machine is a Compaq laptop R3240US. 

/proc/cpuinfo and /proc/interrupts attached along with lsmod output. Sure this machine uses NVidia drivers and thus is tainted but the core problem is reproducible without NVIDIA drivers being loaded.

Version-Release number of selected component (if applicable):
2.6.9-1.667

How reproducible:
Always

Steps to Reproduce:
1. Boot the kernel. 

Actual Results:  Warning in dmesg
warning: many lost ticks.
Losing some ticks... checking if CPU frequency changed.
Your time source seems to be instable or some driver is hogging interupts.


Expected Results:  No lost ticks

Additional info:

Comment 1 Parag Warudkar 2004-11-15 17:35:57 UTC
Created attachment 106727 [details]
/proc/cpuinfo

/proc/cpuinfo

Comment 2 Parag Warudkar 2004-11-15 17:36:37 UTC
Created attachment 106728 [details]
/proc/interrupts

/proc/interrupts

Comment 3 Parag Warudkar 2004-11-15 17:37:18 UTC
Created attachment 106729 [details]
lsmod output

lsmod output

Comment 4 Dave Jones 2005-07-15 20:20:46 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 5 John Caruso 2005-07-28 20:42:56 UTC
This bug is also occurring on 64-bit RHEL4 servers (running kernel
2.6.9-11.ELsmp / x86_64), and doesn't seem to be occurring on a 32-bit RHEL4
server (also running kernel 2.6.9-11.ELsmp).


Comment 6 Parag Warudkar 2005-07-28 21:25:29 UTC
FWIW - John Stultz's new timeofday patches fix this.

Comment 7 Chris Langlands 2005-08-18 08:22:03 UTC
This bug occurs on 60-70% of boots of a RHEL4 2.6.9-11.EL kernel installed on an
IBM Thinkpad 600X Pentium III Coppermine 500Mhz machine. /proc/cpuinfo reports
different MHz and bogomips on each boot.  The unit is connected to power at all
times. 
The other 30-40% of boots the system uses TSC without a problem, and
/proc/cpuinfo reports expected figures.

Comment 8 Dave Jones 2006-01-16 22:14:55 UTC
This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.


Comment 9 Parag Warudkar 2006-01-18 05:15:16 UTC
Long standing mainline kernel issue - let's see if John Stultz's patches work 
around this. Anyway, I don't think it is beneficial keeping this open any 
longer - Closing. Thanks.