"scaling_max_freq" constantly shifting between minimum and maximum frequency
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Expired
|
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_
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/
2201000 2200000 1600000 1200000 800000
:/sys/devices/
ondemand
:/sys/devices/
800000
:/sys/devices/
800000
:/sys/devices/
:/sys/devices/
2.6.24-19-generic
=======
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
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.