Created attachment 26355 [details] dmesg output with cpufreq.debug=7 Hello guys, escalating the bug from our Bugzilla here, so that more eyes scan it. Kernel: Linux version 2.6.33.2-57.fc13.i686.PAE CPU: VIA Esther processor 1200MHz System: Jetway J7F4K1G2E frequency scaling doesn't work after resume. It's stuck to the highest one. dmesg log has a loop: ... __ratelimit: 167 callbacks suppressed cpufreq-core: target for CPU 0: 1200000 kHz, relation 1 acpi-cpufreq: acpi_cpufreq_target 1200000 (0) freq-table: request for target 1200000 kHz (relation: 1) for cpu 0 freq-table: target is 0 (1200000 kHz, 0) cpufreq-core: notification 0 of frequency transition to 1200000 kHz cpufreq-core: notification 1 of frequency transition to 1200000 kHz cpufreq-core: target for CPU 0: 13043 kHz, relation 0 acpi-cpufreq: acpi_cpufreq_target 13043 (0) freq-table: request for target 13043 kHz (relation: 0) for cpu 0 freq-table: target is 1 (400000 kHz, 1) __ratelimit: 70 callbacks suppressed and so on... thanks, Anton.
please attach the output of "grep . /sys/devices/system/cpu/cpu0/cpufreq/*" both before and after suspend.
This machine does not have a suspend mode. # grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:1200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:400000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:10000 /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:1200000 400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:ondemand userspace performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1200000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>
(In reply to comment #2) > This machine does not have a suspend mode. > I mean both before and after a suspend-resume cycle.
this is a server, it's not a laptop. I cannot put it in suspend mode, nor resume.
oh, you're not the bug reporter, :) As this is not the same bug, please file a new bug report for your problem, with detailed description.
I am the user with the problem. The bug reporter, Anton, opened the bug because I originally created a bug report for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=585570). Anton (the bug reporter) does not have this particular piece of hardware and is not able to reproduce the issue. If you want me to run tests, produce logs etc... please let me know, but, this particular piece of hardware does not support suspend/hibernate/resume mode, it's a low power server type hardware.
then I'm wondering why the bug is filed with subject "frequency doesn't scale down after suspend-resume cycle." :p Yves, should I update the subject to "frequency doesn't scale down after boot"? please run "vmstat 1" for several seconds and attach the output. please attach the output of "cat /proc/interrupts" as well.
Created attachment 26528 [details] vmstat -1 output
Created attachment 26529 [details] /proc/interrupts
> I'm wondering why the bug is filed with subject I suspect Anton mixed up two tickets, or maybe my original ticket in the RH bugzilla was misleading. Sorry... > should I update the subject to "frequency doesn't scale down after boot" Well, I would change it to "frequency never scales down", because, it never does, doesn't matter how quite the machine is. Notice that the same problem is present on the last Fedora 13 I tried, while I have a current server at Fedora 9 which scales down and up perfectly, on the exact same hardware. I have attached the output you requested.
with cpufreq.debug=7, please change the governor to userspace, and change the frequency to 400000 mannually. and then attach the dmesg output.
Created attachment 26585 [details] dmesg with cpufreq.debug=7 and governor=userspace switching the governor to userspace, I am able to switch to 400 MHz. The issue is when ondemand, it doesn't clock down on its down.
please attach the output of "grep . /sys/devices/system/cpu/cpu0/cpufreq/ondemand/*" as well. If /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias is set, does clearing this file help?
maybe a cpu-freq governor algorithm problem. Yakui, please look at this issue.
It's great that kernel bugzilla is back. Yves, can you please verify if the problem still exists in the latest upstream kernel?
bug closed as there is no response from the bug reporter. please feel free to reopen it if the problem still exists in the latest upstream kernel.