Re: [gentoo-user] Would constant max CPU speed cause lockups?

[Manuel McLure <manuel@mclure.org>]

[-- 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 --]