Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234219 - 3.2Ghz Pentium D CPU Detected as 6.7Ghz, Slow System Clock Ensues
Summary: 3.2Ghz Pentium D CPU Detected as 6.7Ghz, Slow System Clock Ensues
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Brian Maly
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-27 18:40 UTC by Thomas J. Baker
Modified: 2009-03-11 19:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-11 19:42:35 UTC


Attachments (Terms of Use)
dmesg from affected system (deleted)
2007-03-27 18:40 UTC, Thomas J. Baker
no flags Details

Description Thomas J. Baker 2007-03-27 18:40:53 UTC
Installed RHEl5 Desktop on a Dell Precision 380 workstation with a single
Pentium D 3.2Ghz CPU. The owner immediately noticed how the clock couldn't keep
time. Tried booting with acpi=off, tried updating the system BIOS but neither
helped. Further digging revealed that CPU is being misdetected:

snoopy> cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) D CPU 3.20GHz
stepping        : 4
cpu MHz         : 6700.909
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 3
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni
monitor ds_cpl est cid cx16 xtpr
bogomips        : 21962.72

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) D CPU 3.20GHz
stepping        : 4
cpu MHz         : 6700.909
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni
monitor ds_cpl est cid cx16 xtpr
bogomips        : 14170.83

snoopy> 


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

kernel-2.6.18-8.1.1.el5.i686

Comment 1 Thomas J. Baker 2007-03-27 18:40:53 UTC
Created attachment 151060 [details]
dmesg from affected system

Comment 2 Jarod Wilson 2007-09-02 04:26:38 UTC
Can you try adding 'debug cpufreq.debug=7' to the kernel boot options and post up dmesg output just 
after boot?

Also, you may want to double-check the latest rhel5.1 beta kernels to see if the issue has possibly already 
been addressed:

http://people.redhat.com/dzickus/el5/

Comment 3 Brian Maly 2009-03-11 18:05:11 UTC
There have been no updates in this Bugzilla for quite a while. Can we verify this problem still exists in the newest RHEL5 kernel and close this BZ if the issue issue is resolved?

Comment 5 Thomas J. Baker 2009-03-11 18:30:20 UTC
Yes.

Comment 6 Brian Maly 2009-03-11 19:20:31 UTC
OK, the newest kernel still has this issue.


Comment #1 says the CPU is misdetected. Which CPU/model should instead have been detected?

Also, does booting with "notsc" as a kernel boot arg fix this issue?

Comment 7 Thomas J. Baker 2009-03-11 19:33:17 UTC
Sorry, I misread. I thought you were asking if the current release works, which it does. You can resolve this as closed, currentrelease. I apparently don't have rights too.

Comment 8 Brian Maly 2009-03-11 19:42:35 UTC
Ok, Thanks.

Closing bug.


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