Hi,
(long e-mail, sorry ;-))
Last known good: 3.8.0
Short description:
1. On -rc3, after s2ram cpufreq does not set CPU on max frequency on
high load (on battery).
2. On -rc4 (this is not real regression because I change config
between -rc3 and rc4), "ondemand" does not work. Current frequency is
'strange' (792 MHz).
Detailed description:
1. Kernel 3.8.0:
I try:
# cd /sys/devices/system/cpu
# CPU_LIST="cpu0/cpufreq/ cpu1/cpufreq/ cpu2/cpufreq cpu3/cpufreq"
# for i in $CPU_LIST; do echo -e "\n\n==================\n$i"; grep ''
-R $i/*; done
Output (show only fisrt CPU, others are same):
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0
cpu0/cpufreq//bios_limit:2200000
cpu0/cpufreq//cpuinfo_cur_freq:800000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:10000
cpu0/cpufreq//related_cpus:0 1 2 3
cpu0/cpufreq//scaling_available_frequencies:2200000 2000000 1900000
1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000
1000000 900000 800000
cpu0/cpufreq//scaling_available_governors:ondemand performance
cpu0/cpufreq//scaling_cur_freq:800000
cpu0/cpufreq//scaling_driver:acpi-cpufreq
cpu0/cpufreq//scaling_governor:ondemand
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
It is good: governor "on demand", frequencies also good (800MHz)
CASE 1
Run in other consoles "while true; do echo -n; done" (four times),
power on/off AC power, suspend to ram:
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0
cpu0/cpufreq//bios_limit:2200000
cpu0/cpufreq//cpuinfo_cur_freq:2200000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:10000
cpu0/cpufreq//related_cpus:0 1 2 3
cpu0/cpufreq//scaling_available_frequencies:2200000 2000000 1900000
1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000
1000000 900000 800000
cpu0/cpufreq//scaling_available_governors:ondemand performance
cpu0/cpufreq//scaling_cur_freq:2200000
cpu0/cpufreq//scaling_driver:acpi-cpufreq
cpu0/cpufreq//scaling_governor:ondemand
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
Still is good, governor works as expected.
===============================================================================
Kernel 3.9.0-rc1
$ diff -uNr /boot/config-3.8.0 /boot/config-3.9.0-rc3 | grep -i CONFIG_X86_
CONFIG_X86_64=y
CONFIG_X86_MPPARSE=y
# CONFIG_X86_EXTENDED_PLATFORM is not set
+# CONFIG_X86_INTEL_LPSS is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_PM_TIMER=y
+# CONFIG_X86_INTEL_PSTATE is not set
# CONFIG_X86_PCC_CPUFREQ is not set
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_CPB is not set
CONFIG_X86_PLATFORM_DEVICES=y
CASE 2
After boot:
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0 1 2 3
cpu0/cpufreq//bios_limit:2200000
cpu0/cpufreq//cpuinfo_cur_freq:800000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:10000
cpu0/cpufreq//related_cpus:0 1 2 3
cpu0/cpufreq//scaling_available_frequencies:2200000 2000000 1900000
1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000
1000000 900000 800000
cpu0/cpufreq//scaling_available_governors:ondemand performance
cpu0/cpufreq//scaling_cur_freq:800000
cpu0/cpufreq//scaling_driver:acpi-cpufreq
cpu0/cpufreq//scaling_governor:ondemand
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
(seems be ok)
CASE 3
Run in other consoles "while true; do echo -n; done":
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0 1 2 3
cpu0/cpufreq//bios_limit:2200000
cpu0/cpufreq//cpuinfo_cur_freq:2200000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:10000
cpu0/cpufreq//related_cpus:0 1 2 3
cpu0/cpufreq//scaling_available_frequencies:2200000 2000000 1900000
1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000
1000000 900000 800000
cpu0/cpufreq//scaling_available_governors:ondemand performance
cpu0/cpufreq//scaling_cur_freq:2200000
cpu0/cpufreq//scaling_driver:acpi-cpufreq
cpu0/cpufreq//scaling_governor:ondemand
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
(still seems be ok)
CASE 4
Disconnect AC adapter
(the same as in 'CASE 3')
CASE 5
Suspend to ram and resume
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0 1 2 3
cpu0/cpufreq//bios_limit:2200000
cpu0/cpufreq//cpuinfo_cur_freq:800000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:10000
cpu0/cpufreq//related_cpus:0 1 2 3
cpu0/cpufreq//scaling_available_frequencies:2200000 2000000 1900000
1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000
1000000 900000 800000
cpu0/cpufreq//scaling_available_governors:ondemand performance
cpu0/cpufreq//scaling_cur_freq:800000
cpu0/cpufreq//scaling_driver:acpi-cpufreq
cpu0/cpufreq//scaling_governor:ondemand
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
First error: frequency changed from 2,2GHz (maximum) to 800MHz
(minimum), despite the high CPU load.
CASE 6
Power on AC adapter:
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0 1 2 3
cpu0/cpufreq//bios_limit:2200000
cpu0/cpufreq//cpuinfo_cur_freq:2200000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:10000
cpu0/cpufreq//related_cpus:0 1 2 3
cpu0/cpufreq//scaling_available_frequencies:2200000 2000000 1900000
1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000
1000000 900000 800000
cpu0/cpufreq//scaling_available_governors:ondemand performance
cpu0/cpufreq//scaling_cur_freq:2200000
cpu0/cpufreq//scaling_driver:acpi-cpufreq
cpu0/cpufreq//scaling_governor:ondemand
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
(now back to normal, until AC is disconnected)
===============================================================================
Kernel 3.9.0-rc4
I do some changes:
$ diff -uNr /boot/config-3.9.0-rc3 /boot/config-3.9.0-rc4 | grep -i CONFIG_X86_
CONFIG_X86_64=y
-# CONFIG_X86_INTEL_PSTATE is not set
-# CONFIG_X86_PCC_CPUFREQ is not set
+CONFIG_X86_INTEL_PSTATE=y
+CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_CPB is not set
# CONFIG_X86_POWERNOW_K8 is not set
CASE 7
(normal boot)
CPU:
cpu0/cpufreq/
cpu0/cpufreq//affected_cpus:0
cpu0/cpufreq//cpuinfo_cur_freq:792000
cpu0/cpufreq//cpuinfo_max_freq:2200000
cpu0/cpufreq//cpuinfo_min_freq:800000
cpu0/cpufreq//cpuinfo_transition_latency:4294967295
cpu0/cpufreq//related_cpus:0
cpu0/cpufreq//scaling_available_governors:performance powersave
cpu0/cpufreq//scaling_driver:intel_pstate
cpu0/cpufreq//scaling_governor:powersave
cpu0/cpufreq//scaling_max_freq:2200000
cpu0/cpufreq//scaling_min_freq:800000
cpu0/cpufreq//scaling_setspeed:<unsupported>
(regardless of the cpu load, power, suspend) 'ondemand' governor is
not available.
Config, dmesg:
http://mrutecki.pl/download/kernel/3.9.0-rc4/cpufreq/
Regards
--
Maciej Rutecki
http://www.mrutecki.pl
On 24 March 2013 19:41, Maciej Rutecki <[email protected]> wrote:
> (long e-mail, sorry ;-))
Don't be, it was useful :)
> Last known good: 3.8.0
>
> Short description:
> 1. On -rc3, after s2ram cpufreq does not set CPU on max frequency on high
> load (on battery).
Try attached patch for this.
> 2. On -rc4 (this is not real regression because I change config between -rc3
> and rc4), "ondemand" does not work. Current frequency is 'strange' (792
> MHz).
I don't really have a reason for that :(
But with your config it is clear that, your working setup has:
# CONFIG_X86_INTEL_PSTATE is not set
# CONFIG_X86_PCC_CPUFREQ is not set
CONFIG_X86_ACPI_CPUFREQ=m
and rc4 version has:
CONFIG_X86_INTEL_PSTATE=y
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=m
So, i believe you are using another cpufreq driver this, try with same
configuration once.
> 1. Kernel 3.8.0:
>
> Output (show only fisrt CPU, others are same):
> cpu0/cpufreq//affected_cpus:0
> cpu0/cpufreq//related_cpus:0 1 2 3
> Kernel 3.9.0-rc1
> CASE 2
> After boot:
> cpu0/cpufreq//affected_cpus:0 1 2 3
> cpu0/cpufreq//related_cpus:0 1 2 3
My attached patch will restore 1. instead of CASE 2.
> ===============================================================================
> Kernel 3.9.0-rc4
>
> CASE 7
> (normal boot)
> cpu0/cpufreq//affected_cpus:0
> cpu0/cpufreq//related_cpus:0
This must be related to your different driver.
> Config, dmesg:
> http://mrutecki.pl/download/kernel/3.9.0-rc4/cpufreq/
These were very important and helpful.
On Sunday, March 24, 2013 07:59:35 PM Viresh Kumar wrote:
> On 24 March 2013 19:41, Maciej Rutecki <[email protected]> wrote:
> > (long e-mail, sorry ;-))
>
> Don't be, it was useful :)
>
> > Last known good: 3.8.0
> >
> > Short description:
> > 1. On -rc3, after s2ram cpufreq does not set CPU on max frequency on high
> > load (on battery).
>
> Try attached patch for this.
>
> > 2. On -rc4 (this is not real regression because I change config between -rc3
> > and rc4), "ondemand" does not work. Current frequency is 'strange' (792
> > MHz).
>
> I don't really have a reason for that :(
> But with your config it is clear that, your working setup has:
>
> # CONFIG_X86_INTEL_PSTATE is not set
> # CONFIG_X86_PCC_CPUFREQ is not set
> CONFIG_X86_ACPI_CPUFREQ=m
>
> and rc4 version has:
>
> CONFIG_X86_INTEL_PSTATE=y
> CONFIG_X86_PCC_CPUFREQ=m
> CONFIG_X86_ACPI_CPUFREQ=m
>
> So, i believe you are using another cpufreq driver this, try with same
> configuration once.
>
> > 1. Kernel 3.8.0:
> >
> > Output (show only fisrt CPU, others are same):
> > cpu0/cpufreq//affected_cpus:0
> > cpu0/cpufreq//related_cpus:0 1 2 3
>
> > Kernel 3.9.0-rc1
>
> > CASE 2
> > After boot:
> > cpu0/cpufreq//affected_cpus:0 1 2 3
> > cpu0/cpufreq//related_cpus:0 1 2 3
>
> My attached patch will restore 1. instead of CASE 2.
>
> > ===============================================================================
> > Kernel 3.9.0-rc4
> >
> > CASE 7
> > (normal boot)
> > cpu0/cpufreq//affected_cpus:0
> > cpu0/cpufreq//related_cpus:0
>
> This must be related to your different driver.
Yes, intel_pstate is not really a cpufreq driver. It just overtakes the
whole subsystem.
Dirk, can you please check if this is as intended?
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
2013/3/24 Viresh Kumar <[email protected]>:
> On 24 March 2013 19:41, Maciej Rutecki <[email protected]> wrote:
>> (long e-mail, sorry ;-))
>
> Don't be, it was useful :)
>
>> Last known good: 3.8.0
>>
>> Short description:
>> 1. On -rc3, after s2ram cpufreq does not set CPU on max frequency on high
>> load (on battery).
>
> Try attached patch for this.
>
-rc4 + yours path, config based on -rc3:
# CONFIG_X86_INTEL_PSTATE is not set
# CONFIG_X86_PCC_CPUFREQ is not set
(use acpi-cpufreq)
Freq. seems be ok. 'ondemand' governor works as expected.
Regards
On Sunday, March 24, 2013 04:36:25 PM Maciej Rutecki wrote:
> 2013/3/24 Viresh Kumar <[email protected]>:
> > On 24 March 2013 19:41, Maciej Rutecki <[email protected]> wrote:
> >> (long e-mail, sorry ;-))
> >
> > Don't be, it was useful :)
> >
> >> Last known good: 3.8.0
> >>
> >> Short description:
> >> 1. On -rc3, after s2ram cpufreq does not set CPU on max frequency on high
> >> load (on battery).
> >
> > Try attached patch for this.
> >
> -rc4 + yours path, config based on -rc3:
>
> # CONFIG_X86_INTEL_PSTATE is not set
> # CONFIG_X86_PCC_CPUFREQ is not set
>
> (use acpi-cpufreq)
>
> Freq. seems be ok. 'ondemand' governor works as expected.
Good, thanks for testing.
Viresh, do you want me to apply that patch or are you going to send another
one?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On 24 March 2013 21:28, Rafael J. Wysocki <[email protected]> wrote:
> Good, thanks for testing.
>
> Viresh, do you want me to apply that patch or are you going to send another
> one?
I haven't send it upstream until now as i was waiting for Duncan to reply back.
But as Maciej has tested it now, i will send it upstream and you can apply it.
--
viresh
On 24 March 2013 21:06, Maciej Rutecki <[email protected]> wrote:
> -rc4 + yours path, config based on -rc3:
>
> # CONFIG_X86_INTEL_PSTATE is not set
> # CONFIG_X86_PCC_CPUFREQ is not set
>
> (use acpi-cpufreq)
>
> Freq. seems be ok. 'ondemand' governor works as expected.
Thanks for testing it. I have sent this patch upstream now with your Tested-by.
--
viresh
On 03/24/2013 07:53 AM, Rafael J. Wysocki wrote:
> On Sunday, March 24, 2013 07:59:35 PM Viresh Kumar wrote:
>> On 24 March 2013 19:41, Maciej Rutecki <[email protected]> wrote:
>>> (long e-mail, sorry ;-))
>>
>> Don't be, it was useful :)
>>
>>> Last known good: 3.8.0
>>>
>>> Short description:
>>> 1. On -rc3, after s2ram cpufreq does not set CPU on max frequency on high
>>> load (on battery).
>>
>> Try attached patch for this.
>>
>>> 2. On -rc4 (this is not real regression because I change config between -rc3
>>> and rc4), "ondemand" does not work. Current frequency is 'strange' (792
>>> MHz).
>>> ===============================================================================
>>> Kernel 3.9.0-rc4
>>>
>>> CASE 7
>>> (normal boot)
>>> cpu0/cpufreq//affected_cpus:0
>>> cpu0/cpufreq//related_cpus:0
>>
>> This must be related to your different driver.
>
> Yes, intel_pstate is not really a cpufreq driver. It just overtakes the
> whole subsystem.
>
> Dirk, can you please check if this is as intended?
This is working as intended. The intel_pstate driver has the governor
integrated into the scaling driver and does not use external governors.
The reason the frequency is strange is because intel_pstate returns a
measured value of the effective frequency that the core ran at during
the last time it was sampled.
--Dirk