Bug 34746 - clock timer configuration lost messages
Summary: clock timer configuration lost messages
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-04 18:07 UTC by Matt Domsch
Modified: 2007-04-18 16:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-04 18:14:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Matt Domsch 2001-04-04 18:07:23 UTC
I'm seeing the issue described below on my Dell PowerEdge 2400 running 
qa0401, kernel 2.4.2-0.1.49-i686smp.  Perhaps it's not restricted to VIA?  
System has 2x933MHz, 1GB RAM.

List:     linux-kernel
Subject:  Re: "clock timer configuration lost" error?
From:     Alan Cox <alan@lxorguk.ukuu.org.uk>
Date:     2001-02-26 14:57:47
> Anyone have a clue about the 'probable hdw bug' messages?  No disk
> activity to speak of, no other symptoms and/or messages.

Small number of VIA 686 boxes randomly jump from 100Hz back to the DOS 18Hz
timeout. We dont know if its hardware or maybe APM bios bugs. The kernel 
puts the timer back and life appears happy again

Comment 1 Arjan van de Ven 2001-04-04 18:13:56 UTC
Somehow serverworks machines seem to trigger the message. It's harmless
and the print-priority has been reduced (eg KERN_DEBUG) for newer kernels.

Severworks either has a similar flaw, or a known problem in the code triggers.
The test is slightly inaccurate as there is a small windows during "counter
overflow" where the detection goes wrong. Setting the clock to 100Hz is 
harmless if it is already 100Hz so there is no harm done.
 
We have reduced the priority of the printk to below "user visible" -> resolved


Note You need to log in before you can comment on or make changes to this bug.