GNU bug report logs -
#37904
CPU overheating on recent laptops
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37904 in the body.
You can then email your comments to 37904 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Thu, 24 Oct 2019 14:58:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ludovic Courtès <ludovic.courtes <at> inria.fr>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Thu, 24 Oct 2019 14:58:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
I’ve had reports that Guix System on recent Dell laptops tends to lead
to overheating (with GNOME and all).
According to /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor, all
the CPUs are running on the ‘performance’ governor by default, with
frequencies around 4 GHz (CPUs on these machines range from 400 MHz to
4.7 GHz). So with just a load of 0.3 or so, the CPUs would be at ~65°C
(as reported by ‘sensors’) and the fans would start making noise.
If we explicitly change to the ‘powersave’ governor by writing to /sys,
frequencies go down and the machine behaves better.
However, I would expect UPower to do the right thing in the first
place. Do you know what the story is here? Are we missing some config
bits?
Also, there used to be an “ondemand” governor, which is no longer listed
in /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors.
Was it removed or are we just missing a kconfig option?
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Thu, 24 Oct 2019 16:31:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37904 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludo',
Ludovic Courtès 写道:
> Also, there used to be an “ondemand” governor, which is no
> longer listed
> in
> /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors.
For laptops and other battery-powered devices, ‘conservative’ is
preferred over ‘ondemand’. It's probably a sane default choice
for all.
> Was it removed or are we just missing a kconfig option?
Strange:
~ λ grep CPU_FREQ_GOV …/aux-files/linux-libre/5.3-x86_64.conf
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
What does cpufreq-info say?
Kind regards,
T G-R
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Fri, 25 Oct 2019 20:50:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix <at> gnu.org>
skribis:
> Ludovic Courtès 写道:
>> Also, there used to be an “ondemand” governor, which is no longer
>> listed
>> in /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors.
>
> For laptops and other battery-powered devices, ‘conservative’ is
> preferred over ‘ondemand’. It's probably a sane default choice for
> all.
Oh, didn’t know that one.
>> Was it removed or are we just missing a kconfig option?
>
> Strange:
>
> ~ λ grep CPU_FREQ_GOV …/aux-files/linux-libre/5.3-x86_64.conf
> CONFIG_CPU_FREQ_GOV_ATTR_SET=y
> CONFIG_CPU_FREQ_GOV_COMMON=y
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
Weird, I see:
--8<---------------cut here---------------start------------->8---
$ cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors
performance powersave
performance powersave
performance powersave
performance powersave
$ uname -a
Linux ribbon 5.3.7-gnu #1 SMP 1 x86_64 GNU/Linux
--8<---------------cut here---------------end--------------->8---
Do you see more governors on your side? How could that be?
> What does cpufreq-info say?
On my laptop (plugged in) I have this:
--8<---------------cut here---------------start------------->8---
$ guix environment --ad-hoc cpufrequtils -- cpufreq-info
cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004
Report errors and bugs to linux <at> brodo.de, please.
analyzing CPU 0:
driver: intel_pstate
CPUs which need to switch frequency at the same time: 0
hardware limits: 400 MHz - 3.40 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 3.37 GHz.
analyzing CPU 1:
driver: intel_pstate
CPUs which need to switch frequency at the same time: 1
hardware limits: 400 MHz - 3.40 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 3.25 GHz.
analyzing CPU 2:
driver: intel_pstate
CPUs which need to switch frequency at the same time: 2
hardware limits: 400 MHz - 3.40 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 3.28 GHz.
analyzing CPU 3:
driver: intel_pstate
CPUs which need to switch frequency at the same time: 3
hardware limits: 400 MHz - 3.40 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 3.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 3.31 GHz.
--8<---------------cut here---------------end--------------->8---
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Fri, 25 Oct 2019 20:50:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Fri, 25 Oct 2019 22:20:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
>> For laptops and other battery-powered devices, ‘conservative’ is
>> preferred over ‘ondemand’. It's probably a sane default choice for
>> all.
> --8<---------------cut here---------------start------------->8---
> $ cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors
> performance powersave
> $ uname -a
> Linux ribbon 5.3.7-gnu #1 SMP 1 x86_64 GNU/Linux
> --8<---------------cut here---------------end--------------->8---
>
> Do you see more governors on your side? How could that be?
Do you have a recent Intel CPU? From what I know they removed support
for conservative, because their powersave is in fact conservative.
Also they don’t necessarily stick to the frequency you set for them. To
ensure that they keep the frequency, I have a script running that sets
the speed every minute:
(define cpupower-powersave-job
;; Set the governor to powersave every minute.
;; The job's action is a shell command.
;; TODO: migrate to clearer syntax: #~(job '(next-hour '(3)) (string-append #$btrfs-progs "/bin/btrfs scrub start -c 3 /")))
#~(job "* * * * *" ;Vixie cron syntax
"cpupower frequency-set -g powersave -u 1200000")) ;; use powersave governor with a maximum frequency of 1200MHz
(this is a problem which also hits other distributions)
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Fri, 25 Oct 2019 22:20:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#37904
; Package
guix
.
(Tue, 12 Jul 2022 14:50:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 37904 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
Arne Babenhauserheide <arne_bab <at> web.de> writes:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>>> For laptops and other battery-powered devices, ‘conservative’ is
>>> preferred over ‘ondemand’. It's probably a sane default choice for
>>> all.
>
>> --8<---------------cut here---------------start------------->8---
>> $ cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_available_governors
>> performance powersave
>
>> $ uname -a
>> Linux ribbon 5.3.7-gnu #1 SMP 1 x86_64 GNU/Linux
>> --8<---------------cut here---------------end--------------->8---
>>
>> Do you see more governors on your side? How could that be?
>
> Do you have a recent Intel CPU? From what I know they removed support
> for conservative, because their powersave is in fact conservative.
>
> Also they don’t necessarily stick to the frequency you set for them. To
> ensure that they keep the frequency, I have a script running that sets
> the speed every minute:
>
> (define cpupower-powersave-job
> ;; Set the governor to powersave every minute.
> ;; The job's action is a shell command.
> ;; TODO: migrate to clearer syntax: #~(job '(next-hour '(3)) (string-append #$btrfs-progs "/bin/btrfs scrub start -c 3 /")))
> #~(job "* * * * *" ;Vixie cron syntax
> "cpupower frequency-set -g powersave -u 1200000")) ;; use powersave governor with a maximum frequency of 1200MHz
>
> (this is a problem which also hits other distributions)
Is this problem still an issue? Based on what Arne says above, it seems
it isn't a fault in Guix, so perhaps we can close the issue and seek
resolution upstream if a problem remains?
Thanks,
Maxim
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
You have taken responsibility.
(Tue, 12 Jul 2022 14:56:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ludovic Courtès <ludovic.courtes <at> inria.fr>
:
bug acknowledged by developer.
(Tue, 12 Jul 2022 14:56:03 GMT)
Full text and
rfc822 format available.
Message #28 received at 37904-done <at> debbugs.gnu.org (full text, mbox):
Hi,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> Is this problem still an issue? Based on what Arne says above, it seems
> it isn't a fault in Guix, so perhaps we can close the issue and seek
> resolution upstream if a problem remains?
Yes, looks like we can close it.
Thanks,
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 10 Aug 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.