* Re: [gentoo-user] Would constant max CPU speed cause lockups?
@ 2021-06-06 18:04 99% ` Manuel McLure
0 siblings, 0 replies; 1+ results
From: Manuel McLure @ 2021-06-06 18:04 UTC (permalink / raw
To: gentoo-user
[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]
On Sat, Jun 5, 2021 at 10:18 AM Walter Dnes <waltdnes@waltdnes.org> wrote:
> A few years ago, I cheaped out and bought a low-powered Atom desktop
> with 8 gigs of RAM. Looking back, that was a mistake. It would default
> to 480p or at best 720p on Youtube. But I wrote a nifty bash script
> that manually put the CPU into "userspace" mode, and selected the
> maximum available CPU speed. I finally got Youtube with steady playback
> at 1080p... YAY! I'd leave it at max speed during my waking hours, and
> drop it to min speed at night before going to bed.
>
> I saw the occasional mysterious lockups as I mentioned in recent
> threads. I wonder if pushing the CPU to max speed most of the day would
> cause overheating and lockups. I'm leaving my current, more powerfull,
> machine in "conservative" mode.
>
> Should I stay in conservative mode? Or forget about speed control
> entirely, and let "Intel Speed Step" handle things for me? Also, is
> there a way to enable CPU throttling based on temperature?
>
>
Depending on the specific generation of Atom/Celeron processor, there may
be some issues with processor power control (cstates) that can result in a
lockup. This is a processor bug that affects "Bay Trail" CPUs, including
several Atom processors:
https://ark.intel.com/content/www/us/en/ark/products/codename/55844/products-formerly-bay-trail.html
. I ran into this on a J1900 Celeron that I use to control my 3D printer.
There are a couple of workarounds:
- Disable all cstates >1 with the kernel command line option
"intel_idle.max_cstate=1". This will mean that the processor will not be
able to microsleep to save power.
- Disable cstate 6 (the one that causes the problem) and enable cstate 7
with a shell script like the following:
#!/bin/sh
#title: c6off+c7on.sh
#description: Disables all C6 and enables all C7 core states for Baytrail
CPUs
#author: Wolfgang Reimer <linuxball (at) gmail.com>
#date: 2016014
#version: 1.0
#usage: sudo <path>/c6off+c7on.sh
#notes: Intended as test script to verify whether erratum VLP52 (see
# [1]) is the root cause for kernel bug 109051 (see [2]). In
order
# for this to work you must _NOT_ use boot parameter
# intel_idle.max_cstate=<number>.
#
# [1]
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-n3520-j2850-celeron-n2920-n2820-n2815-n2806-j1850-j1750-spec-update.pdf
# [2] https://bugzilla.kernel.org/show_bug.cgi?id=109051
# Disable ($1 == 1) or enable ($1 == 0) core state, if not yet done.
disable() {
local action
read disabled <disable
test "$disabled" = $1 && return
echo $1 >disable || return
action=ENABLED; test "$1" = 0 || action=DISABLED
printf "%-8s state %7s for %s.\n" $action "$name" $cpu
}
# Iterate through each core state and for Baytrail (BYT) disable all C6
# and enable all C7 states.
cd /sys/devices/system/cpu
for cpu in cpu[0-9]*; do
for dir in $cpu/cpuidle/state*; do
cd "$dir"
read name <name
case $name in
C6*) disable 1;;
C7*) disable 0;;
esac
cd ../../..
done
done
I have been using the above script successfully for over a year.
--
Manuel A. McLure WW1FA <manuel@mclure.org> <http://www.mclure.org>
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat. -- H.P. Lovecraft
[-- Attachment #2: Type: text/html, Size: 5017 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-06-05 17:18 [gentoo-user] Would constant max CPU speed cause lockups? Walter Dnes
2021-06-06 18:04 99% ` Manuel McLure
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox