Re: cpufreq limits avilable frequencies to 800MHz on git kernel

[Arkadiusz Miskiewicz]

On Monday 26 May 2008, Arkadiusz Miskiewicz wrote:
> On Monday 26 May 2008, Thomas Renninger wrote:
> > On Mon, 2008-05-26 at 09:07 +0200, Arkadiusz Miskiewicz wrote:
> > > On Sunday 25 May 2008, Thomas Renninger wrote:
> > > > On Sun, 2008-05-25 at 11:36 +0200, Arkadiusz Miskiewicz wrote:
> > > > > On Saturday 24 May 2008, Andrew Morton wrote:
> > > > > > On Fri, 23 May 2008 19:44:57 +0200 Arkadiusz Miskiewicz
> > > > > > <arekm@xxxxxxxx>
> > > > >
> > > > > wrote:
> > > > > > > thinkpad z60m, Intel(R) Pentium(R) M processor 2.00GHz. kernel
> > > > > > > from git from 1-2 days ago.
> > > > > > >
> > > > > > > Unfortunately it seems that suspend to ram/resume causes
> > > > > > > frequency to be limited to 800MHz only. I can't set it to 2GHz
> > > > > > > again :-/
> > > > > > >
> > > > > > > scaling_max_freq is then 800000 and cannot be changed.
> > > > > > >
> > > > > > > reboot and the problem disappears until new suspend/resume
> > > > > > > cycle.
> > > > > > >
> > > > > > > cpufreq stuff is driven by acpi-cpufreq
> > > > > > >
> > > > > > > $ cpufreq-info
> > > > > > > cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
> > > > > > > Report errors and bugs to linux@xxxxxxxx, 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, 1.60 GHz, 1.33 GHz, 1.07
> > > > > > > GHz, 800 MHz available cpufreq governors: powersave, userspace,
> > > > > > > ondemand, 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.
> > > > > > >
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:800000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:2000000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequenc
> > > > > > >ie s:20 0000 0 1600000 1333000 1066000 800000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governor
> > > > > > >s: powe rsav e userspace ondemand performance
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufre
> > > > > > >q
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performan
> > > > > > >ce /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:800000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000
> > > > > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsuppor
> > > > > > >te d>
> > > > > >
> > > > > > Thanks.  Is this a newly-occurring bug or did earlier kernels do
> > > > > > this also?
> > > > > >
> > > > > > If it was newly added, do you know in which kernel version we
> > > > > > might have added it?
> > > > >
> > > > > I wasn't able to reproduce the problem on final 2.6.24 but was able
> > > > > to reproduce on final 2.6.25. Problem introduced somewhere between
> > > > > it seems.
> > > > >
> > > > > Note that 2-3 suspend to ram/resume cycles is needed to get into
> > > > > the problem.
> > > >
> > > > Sounds related to:
> > > > ï[Bug 374099] T61p speedstep problems (ondemand scheduler)
> > > > ïhttps://bugzilla.novell.com/show_bug.cgi?id=374099
> > >
> > > login/pass protected
> > >
> > > > Miguel speaks from "good boots" and "bad boots".
> > >
> > > Actually I also got "bad boot" (so no suspend/resume was needed).
> > >
> > > > Could you check whether the OS thinks it is too hot.
> > > > ïI described some basics how to monitor temperature and cpufreq (if
> > > > passive cooling kicks in) here:
> > > > https://bugzilla.novell.com/show_bug.cgi?id=387702#c13
> > >
> > > Doesn't seem to be overheated
> > >
> > > [arekm@tarm ~]$ cat
> > > /proc/acpi/thermal_zone/*/{temperature,trip_points,state}; cat
> > > /sys/devices/system/cpu/cpu*/cpufreq/scaling_{cur_freq,max_freq}
> > > temperature:             45 C
> > > critical (S5):           99 C
> > > passive:                 95 C: tc1=5 tc2=4 tsp=600 devices= CPU
> > > state:                   ok
> > > 800000
> > > 800000
> > >
> > > but still limited to 800MHz.
> > >
> > > > Hmm, it may just have been fixed by this one:
> > > > ïcommit e56a727b023d40d1adf660168883f30f2e6abe0a
> > > > Author: Venkatesh Pallipadi <venkatesh.pallipadi@xxxxxxxxx>
> > > > Date:   Mon Apr 28 15:13:43 2008 -0400
> > > >
> > > > Miguel, Geoff: This is already in 11.0 for some time and in 10.3 for
> > > > some days.
> > >
> > > Unfortunately it doesn't fix the problem. The patch is in Linus tree
> > > for long time (so I guess I had it when initially reporting the
> > > problem) + I upgraded today to current git - the problem is still
> > > there.
> >
> > Yep, Dells and some HP should be fixed, it would have been strange if
> > ThinkPads are now also affected, but thanks for double checking, it
> > shows the same symptoms.
> >
> > Then it might be _PPC.
> > If you compile in CPUFREQ_DEBUG and add the boot param:
> > cpufreq.debug=7
> > you should see a message in dmesg (if you do not see one, then
> > everything is fine you have a "good boot" and freq should be at max?):
> > cpufreq_printk("CPU %d: _PPC is %d - frequency %s limited\n", pr->id,
> >                        (int)ppc, ppc ? "" : "not");
> >
> > If PPC is zero all frequencies are allowed, if it is one max_freq will
> > be set to the second highest freq, etc.
> >
> > If it's that you can workaround that (temporarily, pls help evaluating
> > this further) you can use:
> > processor.ignore_ppc=1
> >
> > I remember Ingo Molnar sent a patch to not always evaluate _PPC at
> > boot/initialization time, but only on processor notification events.
> > AFAIK this was a recent ThinkPad, so this might be it what you are
> > seeing. But nobody knew why some ThinkPads had a wrong _PPC value at
> > initialization time.
> >
> > If this is PPC related, this is more an ACPI than a cpufreq issue ->
> > adding linux-acpi list.
>
> Ok, there is something, see:
>
> [ 4093.625227] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
> [ 4095.755272] cpufreq-core: setting new policy for CPU 0: 800000 - 2000000
> kHz [ 4095.755508] acpi-cpufreq: acpi_cpufreq_verify
> [ 4095.755642] freq-table: request for verification of policy (800000 -
> 2000000 kHz) for cpu 0 [ 4095.755780] freq-table: verification lead to
> (800000 - 2000000 kHz) for cpu 0 [ 4095.755916] acpi-cpufreq:
> acpi_cpufreq_verify
> [ 4095.756042] freq-table: request for verification of policy (800000 -
> 800000 kHz) for cpu 0 [ 4095.756179] freq-table: verification lead to
> (800000 - 800000 kHz) for cpu 0 [ 4095.756314] cpufreq-core: new min and
> max freqs are 800000 - 800000 kHz

and later back to 2GHz



[ 4095.756042] freq-table: request for verification of policy (800000 - 800000 
kHz) for cpu 0
[ 4095.756179] freq-table: verification lead to (800000 - 800000 kHz) for cpu 
0
[ 4095.756314] cpufreq-core: new min and max freqs are 800000 - 800000 kHz
[ 4095.756447] cpufreq-core: governor: change or update limits
[ 4095.756575] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[ 4216.175207] __ratelimit: 39 messages suppressed
[ 4216.175414] cpufreq-core: CPU 0: _PPC is 0 - frequency not limited
[ 4216.175553] cpufreq-core: updating policy for CPU 0
[ 4216.175682] acpi-cpufreq: get_cur_freq_on_cpu (0)
[ 4216.175809] acpi-cpufreq: get_cur_val = 100664850
[ 4216.175936] acpi-cpufreq: cur freq = 800000
[ 4216.176061] cpufreq-core: setting new policy for CPU 0: 800000 - 2000000 
kHz
[ 4216.176194] acpi-cpufreq: acpi_cpufreq_verify
[ 4216.176322] freq-table: request for verification of policy (800000 - 
2000000 kHz) for cpu 0
[ 4216.176458] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 
0
[ 4216.176592] acpi-cpufreq: acpi_cpufreq_verify
[ 4216.176719] freq-table: request for verification of policy (800000 - 
2000000 kHz) for cpu 0
[ 4216.176856] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 
0
[ 4216.177405] cpufreq-core: new min and max freqs are 800000 - 2000000 kHz
[ 4216.177565] cpufreq-core: governor: change or update limits
[ 4216.177696] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[ 4230.625012] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
[ 4230.625277] acpi-cpufreq: acpi_cpufreq_target 2000000 (0)
[ 4230.625421] freq-table: request for target 2000000 kHz (relation: 1) for 
cpu 0
[ 4230.625563] freq-table: target is 0 (2000000 kHz, 0)
[ 4230.625698] cpufreq-core: notification 0 of frequency transition to 2000000 
kHz
[ 4230.625838] cpufreq-core: scaling loops_per_jiffy to 7988623 for frequency 
2000000 kHz
[ 4230.625904] cpufreq-core: notification 1 of frequency transition to 2000000 
kHz
[ 4241.624998] __ratelimit: 7 messages suppressed


then back again to 800MHz and back to 2GHz

[ 4313.125215] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
[ 4315.821316] cpufreq-core: setting new policy for CPU 0: 800000 - 2000000 
kHz
[ 4315.821465] acpi-cpufreq: acpi_cpufreq_verify
[ 4315.821525] freq-table: request for verification of policy (800000 - 
2000000 kHz) for cpu 0
[ 4315.821587] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 
0
[ 4315.821648] acpi-cpufreq: acpi_cpufreq_verify
[ 4315.821705] freq-table: request for verification of policy (800000 - 800000 
kHz) for cpu 0
[ 4315.821765] freq-table: verification lead to (800000 - 800000 kHz) for cpu 
0
[ 4315.821826] cpufreq-core: new min and max freqs are 800000 - 800000 kHz
[ 4315.821885] cpufreq-core: governor: change or update limits
[ 4315.821942] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[ 4315.822000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[ 4315.822080] acpi-cpufreq: acpi_cpufreq_target 800000 (0)
[ 4315.822138] freq-table: request for target 800000 kHz (relation: 1) for cpu 
0
[ 4315.822197] freq-table: target is 4 (800000 kHz, 4)
[ 4315.822255] cpufreq-core: notification 0 of frequency transition to 800000 
kHz
[ 4315.822316] cpufreq-core: notification 1 of frequency transition to 800000 
kHz
[ 4315.822370] cpufreq-core: scaling loops_per_jiffy to 3195449 for frequency 
800000 kHz
[ 4459.098165] __ratelimit: 44 messages suppressed
[ 4459.098394] cpufreq-core: CPU 0: _PPC is 0 - frequency not limited
[ 4459.098534] cpufreq-core: updating policy for CPU 0
[ 4459.098663] acpi-cpufreq: get_cur_freq_on_cpu (0)
[ 4459.098791] acpi-cpufreq: get_cur_val = 100664850
[ 4459.098918] acpi-cpufreq: cur freq = 800000
[ 4459.099044] cpufreq-core: setting new policy for CPU 0: 800000 - 2000000 
kHz
[ 4459.099177] acpi-cpufreq: acpi_cpufreq_verify
[ 4459.099321] freq-table: request for verification of policy (800000 - 
2000000 kHz) for cpu 0
[ 4459.099458] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 
0


-- 
Arkadiusz MiÅkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/