Hi Pavel,
I am really confused about where the problem is. 4.8 or 4.9 ? :)
On 04-11-16, 09:58, Pavel Machek wrote:
> On Fri 2016-11-04 09:38:49, Pavel Machek wrote:
> > Hi!
> >
> > I'm debugging overheats on v4.9-rc1... which did not seem to happen in
> > v4.8-rc1. I'm running basically "nice make -j 3" on kernel... cpus are
> > fully loaded.
> >
> > %Cpu(s): 7.5 us, 18.5 sy, 72.6 ni, 0.0 id, 0.0 wa, 0.0 hi, 1.5
> > si, 0.0 st
> > KiB Mem: 3087096 total, 2993076 used, 94020 free, 52900
> > buffers
> > KiB Swap: 1681428 total, 60900 used, 1620528 free. 1183664
> > cached Mem
> >
> > Still, cpus don't stay on maximum frequency on v4.8-rc1. (I suspect
> > that may be why machine does not overheat).
>
> What is worse, they go to low frequency even with "performance"
> governor on v4.8-rc1?!
You sure about it? How did you check it?
Also why are you testing on 4.8-rc1? And not a 4.8 stable kernel? What if the
core is already fixed upstream ?
There is one core fix in 4.8:
commit 899bb6642f2a ("cpufreq: skip invalid entries when searching the
frequency")
> pavel@duo:/sys/devices/system/cpu/cpu0/cpufreq$ sudo cat
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq ; sudo cat
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq ; sudo cat
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq ; sudo cat
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq ; sudo cat
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq ; sudo cat
> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
> 1000000
> 1000000
> 1000000
> 1000000
> 1833000
> 1833000
> 1000000
> 1000000
> 1833000
> 1833000
> 1000000
> 1000000
Is this happening because of thermal capping ? That is the only reason that I
could think of where freq can change with performance governor.
> pavel@duo:/sys/devices/system/cpu/cpu0/cpufreq$ grep -i
> . /sys/devices/system/cpu/cpu0/cpufreq/*
> /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
> /sys/devices/system/cpu/cpu0/cpufreq/bios_limit:1000000
> grep: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:
> Permission denied
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1833000
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:1000000
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:10000
> /sys/devices/system/cpu/cpu0/cpufreq/freqdomain_cpus:0 1
> /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:1833000
> 1333000 1000000
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:conservative
> powersave schedutil ondemand performance
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1000000
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1000000
And this value sort of confirms it.
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1000000
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>
> grep: /sys/devices/system/cpu/cpu0/cpufreq/stats: Is a directory
> pavel@duo:/sys/devices/system/cpu/cpu0/cpufreq$
>
> Let me try v4.9-rc2... that works ok (cpus at the high frequency
> during the kernel build). Unfortunately that sends my cpus to 99C
> temperature range (and eventually forces emergency shutdown).
Unbelievable.
> v4.9-rc2, current policy changes without me touching it. Notice the
> 1.47GHz below? I did not do that, it oscilates itself. Is that thermal
> protection?
Looks like to me.
Can we verify somehow about what's the situation should look like? Perhaps with
some older stable kernel? And then see if 4.8.X works fine or 4.9-rc.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
