Bug 772649

Summary:	Frequency not scaling on demand - Sandy Bridge
Product:	[Fedora] Fedora	Reporter:	Luca Botti <luca.botti>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	high
Version:	16	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, the.ridikulus.rat
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:	2012-02-16 18:58:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Luca Botti 2012-01-09 14:23:38 UTC

Description of problem:
Dell Latitude Laptop, E6420, i7-2760QM CPU @ 2.40GHz, correctly recognized from the kernel (/proc/cpuinfo). Under Heavy load (kvm OR virtualbox windows virtual machine) the clock frequency stays the same (.8 Ghz) for all the four cores (8 threads).
Examining "/sys/devices/system/cpu/cpu0/cpufreq" , I can see the correct limits are detected (cpuinfo_max_freq and cpuinfo_min_freq) and also the correct scaling_driver (acpi-cpufreq) and governor (ondemand).

If I manually do an "echo performance > scaling_governor", I do not see any change.

A possible explanation is that "bios_limit" value is set at 800000 , but:

 - under a certain proprietary OS (windows 7) cpu scaling is behaving normally
 - disabling speedstep in BIOS CPU frequency is up to maximum (2.4 Ghz)


Version-Release number of selected component (if applicable):
Fedora 16 all patches applied, Kernel 3.1.7-1.fc16.x86_64 #1 SMP

How reproducible:
Always


Steps to Reproduce:
1. Start Linux
2. Start a heavy load task
3. watch frequency and load under the /proc or /sys interface (through conky or gnome-system-monitor9
  
Actual results:
CPU Frequency is always at .8 Ghz


Expected results:
CPU Frequency should go up to 2.4 Ghz under load

Additional info:
BIOS Limit set to 800000
disabling speedstep has the cpu working normally

Comment 1 Luca Botti 2012-02-15 10:45:01 UTC

any interest in this?

Comment 2 Luca Botti 2012-02-16 05:50:42 UTC

update: with latest kernel (3.2.6-3.fc16.x86_64), the bios_limit is now set to 1.8 Ghz, and the frequency scales accordingly.

Anyway, the limit is wrong (processor has an upper limit of 2.4)

Comment 3 Dave Jones 2012-02-16 18:58:31 UTC

bios limit is just what we're reading back from the bios, not anything that Linux enforces. Any attempt to try to set a speed higher than that would just be ignored by the bios.

The BIOS sets this lower when it detects overheating, and is supposed to raise it again when things return to normal.

There's nothing we can fix here. At best a BIOS update is about all you can hope for, or as you discovered disable scaling entirely.

Comment 4 Dave Jones 2012-02-17 18:24:26 UTC

something occurred to me. We have an issue with sandybridge systems where can't enable some power management features on the gpu by default, because they cause some machines to lock up.

This may be the reason your system is running hot.
running the i915 driver with i915_enable_rc6=1 might help a little, but the problem that the bios limit isn't being raised is still going to be there.

Comment 5 Luca Botti 2012-02-18 21:29:42 UTC

Hi Dave,

bios_limit is wrong only when SpeedStep is enabled in BIOS, when disabled the maximum frequency (2.4 Ghz) is set and the system works very well.

Max temp reached (from Gnome Shell Extension) is around 69C when I start VirtualBox, nothing more. No issue here with overheating.

Regards