Mark Lord wrote:
Dave Jones wrote:
boot with cpufreq.debug=7, and capture dmesg output after it fails
to transition. This might be another manifestation of the mysterious
"highest frequency isnt accessable" bug, that seems to come from
some recent change in acpi.
booting with that option doesn't seem to give me any new messages
in dmesg (or /var/log/messages). I also tried editing cpufreq.c
and hardcoding debug = 7 on the variable declaration.
Still no new messages.
Mmm.. that's interesting.. this time, the scaling_max_freq went back up
to 1100000 all by itself after a longish idle period, before which it had
dropped to 800000 and got "stuck" there.
Currently using the "ondemand" governor -- it doesn't seem to call the
central cpufreq_debug_printk() thingie from cpufreq.c.
I did hack cpufreq_debug_printk() to force output anytime it gets called,
but still no new output in the logs.
Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
