I can confirm this bug on Dell XPS M1330 using Jaunty upgraded from Intrepid (which was working perfectly).
This happens to me not only after suspend/resume but also after I disconnect AC power and then reconnect it. Frequency is then locked at 800MHz with no related messages in logs.
As it was already pointed out, directly writing max value to cpu{0,1}/cpufreq/scaling_max_freq has no effect.
# uname -a
Linux led 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:31:32 UTC 2009 x86_64 GNU/Linux
# cpufreq-info
cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0
hardware limits: 800 MHz - 2.00 GHz
available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 800 MHz. The governor "performance" may decide which speed to use within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
cpufreq stats: 2.00 GHz:1,38%, 2.00 GHz:0,18%, 1.60 GHz:0,18%, 1.20 GHz:0,21%, 800 MHz:98,05% (378)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 1
hardware limits: 800 MHz - 2.00 GHz
available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 800 MHz. The governor "ondemand" may decide which speed to use within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
cpufreq stats: 2.00 GHz:0,62%, 2.00 GHz:0,67%, 1.60 GHz:0,14%, 1.20 GHz:0,17%, 800 MHz:98,40% (535)
I can confirm this bug on Dell XPS M1330 using Jaunty upgraded from Intrepid (which was working perfectly).
This happens to me not only after suspend/resume but also after I disconnect AC power and then reconnect it. Frequency is then locked at 800MHz with no related messages in logs.
As it was already pointed out, directly writing max value to cpu{0,1} /cpufreq/ scaling_ max_freq has no effect.
# uname -a
Linux led 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:31:32 UTC 2009 x86_64 GNU/Linux
# cpufreq-info
The governor "performance" may decide which speed to use
within this range.
The governor "ondemand" may decide which speed to use
within this range.
cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0
hardware limits: 800 MHz - 2.00 GHz
available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 800 MHz.
current CPU frequency is 800 MHz (asserted by call to hardware).
cpufreq stats: 2.00 GHz:1,38%, 2.00 GHz:0,18%, 1.60 GHz:0,18%, 1.20 GHz:0,21%, 800 MHz:98,05% (378)
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 1
hardware limits: 800 MHz - 2.00 GHz
available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
available cpufreq governors: conservative, ondemand, userspace, powersave, performance
current policy: frequency should be within 800 MHz and 800 MHz.
current CPU frequency is 800 MHz (asserted by call to hardware).
cpufreq stats: 2.00 GHz:0,62%, 2.00 GHz:0,67%, 1.60 GHz:0,14%, 1.20 GHz:0,17%, 800 MHz:98,40% (535)