Ubuntu

"scaling_max_freq" constantly shifting between minimum and maximum frequency

Reported by Viktor Kojouharov on 2008-06-21
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

This is a regression in Hardy, as this behaviour was not present in Gutsy

With the upgrade to hardy (and the new 2.6.24 kernel), the cpu frequency switching started misbehaving quite badly. Regardless of the system load, the "scaling_max_freq" value will suddently, but quickly, decrease (pass through all available middle frequencies) until it reaches the lowest available frequency. Then, it will stay there for a duration of time (more than 10 minutes), regardless of the system load. During this time, it is not possible to raise the cpu frequency in any way. switching the governor from "ondemand" to "performance" has no effect (probably because of the limiting factor of "scaling_max_freq"). After this undefined period of time is over, the value of the "scaling_max_freq" will quickly rise to its maximum value, passing through each available frequency in between.

This cycle of maximum frequency change repeats indefinitely, at seemingly random intervals. Furthermore, it is not possible to change the "scaling_max_freq" value. Although echoing a new valid value with not produce any errors, a 'cat' immediately after the echo will show the old value.

This is some information while the cycle is in its minimum phase:
===============================================
:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_available_frequencies
2201000 2200000 1600000 1200000 800000
:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_governor
ondemand
:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_min_freq
800000
:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_max_freq
800000
:/sys/devices/system/cpu/cpu0/cpufreq$ uptime
                               load average: 1.43, 1.47, 1.45
:/sys/devices/system/cpu/cpu0/cpufreq$ uname -r
2.6.24-19-generic
===============================================

Viktor Kojouharov (vkojouharov) wrote :

some additional info:

forgot to add to the description that the cpu is an intel core 2 duo t7500

This behaviour also occurs in a vanilla 2.6.25.7 kernel.

Also, setting the scaling_min_freq value to the maximum value before the start of the cycle does not stop it. Furthermore, when the system is under a lot of load (compiling a kernel, playing a cpu-intensive game), the cpu is always scaled to its lowest value, although this may just be a coincidence.

gthomas (gt-launchpad) wrote :

I confirm that this behaviour occurs with 2.6.26-5-generic kernel on Intel T7200.

BUT also the cpu ventillator goes high speed - after I provided some better ventillation, and the vents calm down, the scaling_max_freq went back to 2GHz and the machine is as responsive as should be.
So this is maybe a better CPU/thermal govern?

GT

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

kernel-janitor (kernel-janitor) wrote :

Hi vkojouharov,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux-image-`uname -r` 242006

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete

Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=/dev/sda10
MachineType: Dell Inc. Latitude D620
NonfreeKernelModules: ramzswap xvmalloc nvidia
Package: linux-image-2.6.30-10-generic 2.6.30-10.12
PackageArchitecture: i386
ProcCmdLine: root=UUID=7971d6f3-cdf9-4d3c-ae67-cb355ae35e1c ro rootfstype=ext4 quiet splash
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=hu_HU.UTF-8
 LANGUAGE=hu_HU:hu:en_GB:en
ProcVersionSignature: Ubuntu 2.6.30-10.12-generic
RelatedPackageVersions:

UdevDb: Error: [Errno 2] No such file or directory
Uname: Linux 2.6.30-10-generic i686
UserGroups: adm admin audio cdrom dialout kvm libvirtd lpadmin netdev plugdev pulse-rt sambashare
dmi.bios.date: 04/03/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A08
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA08:bd04/03/2007:svnDellInc.:pnLatitudeD620:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude D620
dmi.sys.vendor: Dell Inc.

Changed in linux (Ubuntu):
status: Incomplete → New
tags: added: apport-collected
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
vava (vadim-atlygin) wrote :

Exactly this bug happens on my laptop but only when it is on battery and CPU is under load (> 30%). Could it be that it just don't have enough power?

Felix (apoapo) wrote :

on my machine it was a heat problem. you could try cpu burn tests and see if it happens when your cpu is getting too hot (>100°)

vava (vadim-atlygin) wrote :

Ok, I'll try, but I should add that under Windows it all works fine no matter what CPU temperature are and whether laptop is on battery or not :)

vava (vadim-atlygin) wrote :

I've tried on 85 degrees, everything works as expected. It took me half an hour to reach this temperature with burnBX and burnP6 running in parallel, so I think my cooling system works ok :)

But scaling_max_freq goes down to 800000 the exact moment I run everything remotely CPU intensive when laptop is on battery power. The moment I turn AC power on, it goes back to 2000000.

Felix (apoapo) wrote :

You are sure that this isn't just your powermanagement trying to save power? You can set it to powersave or conservative powersave e.g. The powermanager uses the max scaling freq as a tool to limit cpu to a lower frequencye due to energysaving.

vava (vadim-atlygin) wrote :

No, it's not power management. Even if I set governor to userspace or performance, frequency still goes from 2GHz to 800Mhz.

But I just did a quick experiment and turns out you are right, it is temperature based. The only problem is, the border line is set to 50 degrees Celsius. If temperature is below that point, maximum frequency is 2Ghz, if it is above it, it drops to 800MHz. But only on battery power, when on AC I suspect the border temperature is much higher.

But I can't keep my CPU under 50 degrees, it's just impossible :)

vava (vadim-atlygin) wrote :

Huh, turns out there was a setting in BIOS that controls SpeedStep, it was set to "Optimize battery" when on battery. Changing it to "automatic" cured the problem.

Cyril Jaquier (cyril-jaquier) wrote :

I was also affected by this bug and I just solved it on my Thinkpad T61 by... blowing 3-4 times into the cooling system!!! Lots of dust escaped so I think my laptop just needs a bit of cleanup ;-) Now bios_limit stays at the highest level even under high load.

$ cat /sys/devices/system/cpu/cpu*/cpufreq/bios_limit
2201000
2201000

Viktor Kojouharov, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

tags: removed: apport-collected
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers