Description of problem: Having a Intel x346 Server, 4 Socket holding a dualcore Xeon (Paxville) each, using the -xen kernel does show wrong values in /proc/cpuinfo: # uname -a Linux ls3121 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Genuine Intel(R) CPU 3.00GHz stepping : 8 cpu MHz : 3002.586 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 cid cx16 xtpr lahf_lm bogomips : 6008.87 clflush size : 64 cache_alignment : 128 address sizes : 40 bits physical, 48 bits virtual power management: whereas: # uname -a Linux ls3121 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Genuine Intel(R) CPU 3.00GHz stepping : 8 cpu MHz : 4246.996 cache size : 2048 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 cid cx16 xtpr lahf_lm bogomips : 10598.66 clflush size : 64 cache_alignment : 128 address sizes : 40 bits physical, 48 bits virtual power management: Mhz differ for both kernels: std: cpu MHz : 3002.586 <-- correct xen: cpu MHz : 4246.996 <-- wrong! Version-Release number of selected component (if applicable): # rpm -q kernel kernel-2.6.18-8.el5 # rpm -q kernel-xen kernel-xen-2.6.18-8.el5 How reproducible: always Steps to Reproduce: 1. boot kernel (xen or standard) 2. cat /proc/cpuinfo Actual results: xen kernel shows wrong Mhz Expected results: xen kernel shows correct Mhz
Can you please check if this is still an issue with RHEL-5.4? There have been many, many timer fixes since this was reported against 5.0, and those timer fixes have also fixed some situations where we would wrongly report CPU information. If this works in 5.4, we can close this out. Thanks, Chris Lalancette
Sorry, I cannot verify if the problem is fixed with RHEL5.4 because the particular machine with the particular CPU types showing this issue is no longer in our lab. Therefore I close this bug.