Bug 435910

Summary:	Cpu frequency adjustments not working on all systems with Xen kernel
Product:	Red Hat Enterprise Linux 5	Reporter:	Bill Burns <bburns>
Component:	kernel-xen	Assignee:	Rik van Riel <riel>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.2	CC:	jarod, xen-maint
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-04-02 16:24:19 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:

Description Bill Burns 2008-03-04 13:06:28 UTC

Description of problem:
On an Intel SDV box loaded with the pre-beta of RHEL 5.2 the cpspeed program is
not being started. Everything looks correct, but the program does not run. It
can be manually started and the cpuspeed adjustments seem to work fine.

Version-Release number of selected component (if applicable):
The nightly install was from 2/29/2008 and has the -83 kernel.


How reproducible:
Start/stop the cpuspeed service and note that the actual program is not running.


Steps to Reproduce:
service cpuspeed start

1.
2.
3.
  
Actual results:
No cpuspeed process is visible. No speed changes occur.

Expected results:
Should be a cpuspeed process.

Additional info:
System was installed as a non-virt system (since this box's graphics are not
working with Xen & X). Manually loaded the Xen kernel and user space RPMs.
Contents of /proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz
stepping        : 11
cpu MHz         : 2000.000
cache size      : 4096 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
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 nx lm constant_tsc pni monitor
ds_cpl vmx smx est tm2 cx16 xtpr lahf_lm
bogomips        : 7491.06
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     E6850  @ 3.00GHz
stepping        : 11
cpu MHz         : 2000.000
cache size      : 4096 KB
physical id     : 1
siblings        : 1
core id         : 0
cpu cores       : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
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 nx lm constant_tsc pni monitor
ds_cpl vmx smx est tm2 cx16 xtpr lahf_lm
bogomips        : 7491.06
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Comment 1 Jarod Wilson 2008-03-04 18:58:15 UTC

So we have a touch of confusion here...

The cpuspeed daemon should only run on older hardware, with recent hardware
(such as this), we use in-kernel frequency scaling (we default to the ondemand
driver). So the cpuspeed initscript is actually doing the expected thing here,
loading up acpi-cpufreq and enabling in-kernel frequency scaling via the
ondemand governor. All the sysfs bits even look correct:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
3000000 2667000 2333000 2000000

The problem here is that we're simply never scaling down the speed for some
reason. This would appear to be a bug in acpi-cpufreq driver or the ondemand
governor. Lets double-check whether or not we get the same behavior with a
bare-metal kernel, to know if its a generic problem or a xen-specific one...

Comment 2 Bill Burns 2008-03-05 21:26:34 UTC

I booted the non-Xen kernel and indeed observed that the cpu frequency scaling
was working on this system. Thus it appears to be an issue with the Xen kernel.
Changed the summary to better reflect the bug.

Comment 3 Jarod Wilson 2008-03-24 02:55:34 UTC

Since it appears the cpuspeed package is doing everything its supposed to here,
and scaling works as expected on bare metal, I'm reassigning this over to
kernel-xen, as the problem appears to be specific to xen's cpu frequency scaling
implementation. Riel, tag, you're it! ;)

Comment 4 Rik van Riel 2008-03-24 14:22:44 UTC

Bill, can you manually adjust the CPU frequencies through /sys or does that also
fail?

Lets figure out if it is a governor problem or a cpuspeed driver problem on your
hardware...

Also, does the hypervisor print out any messages about non-allowed MSR writes?

Comment 5 Jarod Wilson 2008-03-24 14:34:40 UTC

I'd wager its a governor issue. If you switch the box over to the 'userspace'
governor (i.e., run the cpuspeed daemon), it appears to do the right thing. At
least, that's my recollection...

Comment 6 Bill Burns 2008-04-02 16:24:19 UTC

System had old bios. After an upgrade thins are working as expected. Closing
this bug.