[SOLVED] 14.2 slow after update to 4.4.153

Updated 14.2 from 4.4.144 to 4.4.153. System ran slower afterwards, especially X.

This is an older system which has run slack for many years: Pentium(R) 4 CPU 3.00GHz, ATI Radeon X1650, up to date with Slack14.2 patches, and has a few X packages compiled from Slackware-Current. (No, I'm not buying a new PC. Landfills have enough digital junk already.)

4.4.144 seems to run as expected. 4.4.153 graphics in Seamonkey are especially slow. A diff on the 4.4.144 and 4.4.153 kernel configs shows nothing notable.

Anyone else seen anything similar?

Thanks,
Halsey

I found seamonkey slow in _anything_ I opened it in. KDE also. You'd have an old or underpowered system (like mine, or yours) on life support running those things. Are the proprietary graphics drivers loading? It might be software rendering, which is cpu intensive.

BTW +1 on the 'Landfills have enough digital junk already.'

Originally Posted by HalseyTaylor Updated 14.2 from 4.4.144 to 4.4.153. System ran slower afterwards, especially X. This is an older system which has run slack for many years: Pentium(R) 4 CPU 3.00GHz, ATI Radeon X1650, up to date with Slack14.2 patches, and has a few X packages compiled from Slackware-Current. (No, I'm not buying a new PC. Landfills have enough digital junk already.) 4.4.144 seems to run as expected. 4.4.153 graphics in Seamonkey are especially slow. A diff on the 4.4.144 and 4.4.153 kernel configs shows nothing notable. Anyone else seen anything similar? Thanks, Halsey

Your issue looks similar with https://www.linuxquestions.org/quest...ml#post5897972

And that behavior itself looks similar with what happened in the x86_64 world after implementation of protections against Spectre/Meltdown, maybe exacerbated by the low computing power of your system(s).

Maybe they started to add that to the x86 too. So, my suggestion is to try to disable those (supposed) protections with "nopti" on kernel command line and see if that changes something.

@HalseyTaylor

As Darth Vader suggested, the cause of the performance loss might come from the Intel vulnerabilities mitigations, however, in the changelog of 4.4.153 it's only describing some changes related to L1TF:
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.153
Given that your CPU is really old and according to Intel not affected by any of these newly discovered vulnerabilities, I believe it's safe for you to disable them with the help of some kernel boot parameters.
Given your actual situation and the changes in 4.4.153, I'd start with disabling the L1TF mitigation:

l1tf=off

and check for any performance improvements.
To disable all these new mitigations, at least on the level permitted/documented, the following kernel boot parameters are to be used:

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier

Lecture:
https://git.kernel.org/pub/scm/linux...6adf9c1e17aa2d
https://www.kernel.org/doc/html/late...lt-mitigations

Originally Posted by abga @HalseyTaylor As Darth Vader suggested, the cause of the performance loss might come from the Intel vulnerabilities mitigations, however, in the changelog of 4.4.153 it's only describing some changes related to L1TF: https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.153 Given that your CPU is really old and according to Intel not affected by any of these newly discovered vulnerabilities, I believe it's safe for you to disable them with the help of some kernel boot parameters. Given your actual situation and the changes in 4.4.153, I'd start with disabling the L1TF mitigation: l1tf=off and check for any performance improvements. To disable all these new mitigations, at least on the level permitted/documented, the following kernel boot parameters are to be used: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier Lecture: https://git.kernel.org/pub/scm/linux...6adf9c1e17aa2d https://www.kernel.org/doc/html/late...lt-mitigations

But 'l1tf' and 'stf' are not mentioned in /usr/src/linux-4.4.153/Documentation/kernel-parameters.txt

Originally Posted by slalik But 'l1tf' and 'stf' are not mentioned in /usr/src/linux-4.4.153/Documentation/kernel-parameters.txt

Right, I thought you already tried l1tf=off.
The l1tf switch is documented for the l1tf patch:
https://www.kernel.org/doc/html/late...uide/l1tf.html

As for no_stf_barrier, it looks like only applicable for PowerPC (I should have checked that):
https://github.com/torvalds/linux/bl...nel/security.c

For x86, the following will qualify:

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable

A P4 is still post 1995 and affected by many of the vulnerabilities. It's not that old.

Bios date is 2006. This system's been on life support for years Plays Portal2 and HL2 on the XP boot side just fine.

Kernel boot parameters didn't seem to have much effect.

This system sits behind NAT and has a pretty good rc.firewall. It gets turned off when not in use. It's not like it's a server facing the world. Downgrading to 4.4.88, the last slack kernel before spectre/meltdown came up, seems to work fine.

Part of the problem is that with hardware acceleration, the video card is quirky (X1650 GT) with the radeon X-driver: it intermittently locks up. This usually happens when updating video, and a keyboard or USB service request comes in. So, it runs in software mode.

It ran great with the FGLRX module. But, that's not been available to this card for a while. It's never been clear whether the lockups happen at the DRM level or the X driver level.

It runs fine for most things so it stays out of the landfill. True, I can't view web pages creptified with tons of CSS & javascript and superfluous images. But, it displays the useful stuff well enough. Javascript is toggled off which helps a lot.

Originally Posted by HalseyTaylor Bios date is 2006. This system's been on life support for years Plays Portal2 and HL2 on the XP boot side just fine. Kernel boot parameters didn't seem to have much effect. This system sits behind NAT and has a pretty good rc.firewall. It gets turned off when not in use. It's not like it's a server facing the world. Downgrading to 4.4.88, the last slack kernel before spectre/meltdown came up, seems to work fine. Part of the problem is that with hardware acceleration, the video card is quirky (X1650 GT) with the radeon X-driver: it intermittently locks up. This usually happens when updating video, and a keyboard or USB service request comes in. So, it runs in software mode. It ran great with the FGLRX module. But, that's not been available to this card for a while. It's never been clear whether the lockups happen at the DRM level or the X driver level. It runs fine for most things so it stays out of the landfill. True, I can't view web pages creptified with tons of CSS & javascript and superfluous images. But, it displays the useful stuff well enough. Javascript is toggled off which helps a lot.

I know pretty well that behavior with relative old Radeon graphics cards under Slackware 14.2 and I am glad that 2 years later someone else confirms those freezes.

I used to call it with affection (or exasperation?) just "IT FREEZE!" and it appears even in more powerful boxes which are unlucky to sports a budget Radeon video-card.

Was not spared even a mighty Bulldozer with 8 cores and 32GB RAM DDR3 1600MHz, but with an Radeon HD6450.

And those freezes appearing on Slackware 14.2 on all my 6 AMD computers (all with budget Radeon graphics) is the reason behind the fact that I followed like a hound the Slackware 15 development cycle.

Long story short, to fix those freezes you shall upgrade the graphics stack like in slackware-current, building from sources: kernel, LLVM, Mesa3D (and libDRM) and X.org (and its drivers)

It is a lot of work, but you have a nice bonus above the system stability: the graphics will behave much much better and much snappy.

I believe that's worth to try even with your old Pentium 4.

FWIW, I had an X1250(Slightly earlier) probably manufactured 2007, and a twin Turion, and the card was crap - I mean really crap. It couldn't lip synch on full screen video. I rebuilt with LLVM (a real pain in the butt back then) because the heads in Radeon Dev told me to: Apparently I had no vertex shader (Whatever that is). It made sod all difference.

Originally Posted by business_kid FWIW, I had an X1250(Slightly earlier) probably manufactured 2007, and a twin Turion, and the card was crap - I mean really crap. It couldn't lip synch on full screen video. I rebuilt with LLVM (a real pain in the butt back then) because the heads in Radeon Dev told me to: Apparently I had no vertex shader (Whatever that is). It made sod all difference.

It wasn't about vertex shaders. After all, a Radeon HD6450 has 160 vertex shaders and still had problems. Let's say, it was more about an unfortunate recipe for the graphics stack.

Anyways, the Radeon X1250 is what sports the chipset RS690 and this was on ones of motherboards well appreciated in Romania, for its 14W power consumption and decent performances with AM2 45W processors.

Also, it is the chipset on Acer Veriton L410 (see the screenshot), a mini-PC which invaded Romania (as second-hand boxes) because it is very appreciated for HTPCs or small browsing/multimedia PCs, while the shops asks for crazy prices for HTPC hardware.

Believe or not, in my country is cheaper to build a beast box than a HTPC. And the latest trend here is orientation to small PCs instead of overpowered beasts.

And I am pretty sure that it works more than decent with the current graphics stack from Slackware-current, Fedora, OpenSUSE Leap or Ubuntu. Because I seen it in action, being used by many of my friends.

Hmm... Last December, the LLVM, Mesa3D, and libDRM were upgraded using what was in -current at the time. This got glamor running on the X1650 - which it couldn't do before. Ran pretty hot, tho. But, kernel was 4.9. You're right, upgrading was a pain.

Think I'll wait for Slack15, then load it all to a new hard drive and see what happens.

It's funny, going to the smaller PC's and working in the cloud. Back in my day, we called them VT-220's and they worked in the mainframe.

Originally Posted by HalseyTaylor Bios date is 2006. This system's been on life support for years Plays Portal2 and HL2 on the XP boot side just fine. Kernel boot parameters didn't seem to have much effect. This system sits behind NAT and has a pretty good rc.firewall. It gets turned off when not in use. It's not like it's a server facing the world. Downgrading to 4.4.88, the last slack kernel before spectre/meltdown came up, seems to work fine.

Sorry to hear the kernel boot parameters disabling the CPU vulnerabilities mitigations had no effect. I wish I could run some tests myself, but I have no old HW anymore (P4 CPUs). The oldest and apparently most secure CPU I own ATM is an Intel Atom N270 (decade old Acer Aspire One - sub-notebook) that runs fine with 4.4.153. Actually it's not that secure because it has Hyper-Threading activated and might suffer from the TLBleed vulnerability.

Originally Posted by business_kid A P4 is still post 1995 and affected by many of the vulnerabilities. It's not that old.

https://www.intel.com/content/www/us...-sa-00088.html

HalseyTaylor --

If you're interested, below my sig is a script that I run after every kernel update to look for certain changes to state of the S&M Mitigation wac-a-mole game.

I do understand that your post is marked [SOLVED] and that the performance regression may not be specifically related to any particular S&M Mitigation but there is some good info in the output that might help discover the status of S&M mitigations for your Pentium 4.

For example. this is the output for a Celeron N3160 ... note under the 'cpuinfo' section that there is no Firmware File for the Family, Model, Stepping Values for the CPU.

# ./.do-get-spectre-meltdown.sh x 

Mon Sep  3 05:42:25 CDT 2018

  Linux bi3252 4.4.153 #1 SMP Tue Aug 28 16:08:22 CDT 2018 x86_64 Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz GenuineIntel GNU/Linux

  dmesg
    Linux version 4.4.153 (root@hive64.slackware.lan) (gcc version 5.5.0 (GCC) ) #1 SMP Tue Aug 28 16:08:22 CDT 2018
    Command line: auto BOOT_IMAGE=Slack44153U ro root=803 vt.default_utf8=0
    DMI: ZOTAC ZBOX-BI325/ZBOX-BI325, BIOS B273P022 03/09/2017

  cpuinfo
    UCode Pkg:  intel-microcode-20180807a-noarch-1_SBo_kjh  ( updated Aug 31 10:09 )
    CPU FMS:    06-4c-04
    Firmware:   no firmware file for 06-4c-04
    CPU bugs:   cpu_meltdown spectre_v1 spectre_v2
    Microcode:  0x403

  vulnerabilities
    l1tf:                Not affected
    meltdown:            Mitigation: PTI
    spec_store_bypass:   Not affected
    spectre_v1:          Mitigation: __user pointer sanitization
    spectre_v2:          Mitigation: Full generic retpoline

OTOH, this is the same output for my primary Work Laptop:

# ./.do-get-spectre-meltdown.sh -w

Mon Sep  3 05:43:36 CDT 2018

  Linux kjhlt6 4.4.153 #1 SMP Tue Aug 28 16:08:22 CDT 2018 x86_64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz GenuineIntel GNU/Linux

  dmesg
    microcode: CPU0 microcode updated early to revision 0xc6, date = 2018-04-17
    Linux version 4.4.153 (root@hive64.slackware.lan) (gcc version 5.5.0 (GCC) ) #1 SMP Tue Aug 28 16:08:22 CDT 2018
    Command line: BOOT_IMAGE=Slack44153T ro root=803 vt.default_utf8=0 elevator=noop ipv6.disable=1
    DMI: Notebook P7xxDM(-G) /P7xxDM(-G), BIOS 1.05.03LS1 09/23/2015

  cpuinfo
    UCode Pkg:  intel-microcode-20180807a-noarch-1_SBo_kjh  ( updated Aug 28 10:08 )
    CPU FMS:    06-5e-03
    Firmware:   /lib/firmware/intel-ucode/06-5e-03  ( updated Aug 28 10:07 )
    CPU bugs:   cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
    Microcode:  0xc6

  vulnerabilities
    l1tf:                Mitigation: Page Table Inversion
    meltdown:            Mitigation: PTI
    spec_store_bypass:   Mitigation: Speculative Store Bypass disabled via prctl and seccomp
    spectre_v1:          Mitigation: __user pointer sanitization
    spectre_v2:          Mitigation: Full generic retpoline, IBPB, IBRS_FW

Anyhow, some of the output might provide clues as to which Mitigations to even bother with for your Pentium 4.

-- kjh

This is my /root/tmp/.do-get-spectre-meltdown.sh script ( please don't make fun of my coding style ( or lack thereof ) )

By default .do-get-spectre-meltdown.sh will spew output on the screen -AND- append the output to /root/tmp/vuln-`uname -r`.txt ( example: /root/tmp/vuln-4.4.153.txt )

The script does not create /root/tmp/ directory ( you can change line 9 if you want a different directory ) !

Invoke with ANY Arg to not append to the file ( example: .do-get-spectre-meltdown.sh -w )

I always invoke the script as root after installing and booting a new kernel.

#!/bin/bash
#
# any commandline arg will prevent file output
#
[ $# -gt 0 ] && DoFile=0 || DoFile=1
#
# OutDir is the output Directory
#
OutDir="/root/tmp"           # edit me
#
# don't write to / 
#
[ "$OutDir" = "" ] && OutDir="."
#
# turn off DoFile and whine if DoFile and OurDir does not exist or is illegal
#
if [ "$OutDir" = "" -o ! -d "$OutDir" ]
then
   if [ "$DoFile" = "1" ]
   then

      [ "$FooDir" = "" ] && FooDir="/" || FooDir="$OutDir"

      echo "No File Output because I cannot create files in OutDir = \"$FooDir\"" >&2
      DoFile=0
   fi
fi
#
# handy functions here
#
# scoot over 3-spaces or set via `Tab -t <<TabStop>>`
#
Tab ()
{
   
   TabStop=3
   TabStr=""

   while  getopts t: junk 2>/dev/null
   do
      case $junk in
         t)    TabStop=$OPTARG ;;
      esac
   done
   
   shift `expr $OPTIND - 1`

   if [ $TabStop -le 0 ]
   then
      cat $@
   else

      TabStr="$(printf "%-${TabStop}s" "" )"

      sed -e "s/^/${TabStr}/" $@
   fi
}
#
# parse an ls -la listing and write with 'style'
#
ParseLsLa ()
{
   gawk '
   {
      if ( match( $1, /^.r......../ ))
      {
         print $(NF) "  ( updated " $(NF-3) " " $(NF-2) " " $(NF-1) " )"
      }
      else
      {
         print
      }
   }' "$@"
}
#
# formatted dump of /sys/devices/system/cpu/vulnerabilities/*
#
GetSMVuln ()
{
   if [ ! -d /sys/devices/system/cpu/vulnerabilities ]
   then
      echo "the kernel reports no CPU vulnerabilities"
      return 1
   fi

   gawk '
   BEGIN {
   
      Fmt = "%-20s %s\n"
   }
   # main
   {
      N = split( FILENAME, A, "/" )
      F = $0
   
      printf( Fmt, A[N] ":", F )
   
   }' /sys/devices/system/cpu/vulnerabilities/*

   return $?
}
#
# print 'interesting' lines from /proc/cpuinfo
#
ProcCPUInfo ()
{
   gawk '
   BEGIN {
   
      FS = ":"

      Bugs = UCode = ""

      Fam  = Model = Step = N = 0

      IntelPath = "/lib/firmware/intel-ucode/"
   }
   function ParseLsLa( File,   OldFS, N, A )
   {
      if ( match( File, /^.r......../ ))
      {
         if (( N = split( File, A, " " )) >= 4 )
         {
            return( A[N] "  ( updated " A[N-3] " " A[N-2] " " A[N-1] " )" )
         }
      }
      return( File )
   }
   function GetFirmWare( Path, FMS,   OutStr, PipeCmd )
   {
      OutStr = ""

      if ((( L = length( Path )) > 0 ) && ( substr( Path, L, 1 ) != "/" ))
      {
         Path = Path "/"
      }
      Path = Path FMS

      PipeCmd = "/bin/ls -lad " Path " 2>/dev/null"

      PipeCmd | getline OutStr

      close( PipeCmd )

      if ( OutStr != "" )
      {
         return( ParseLsLa( OutStr ))
      }
      return( OutStr )
   }
   # main
   {
      if ( match( $1, /^bugs[\t]*$/ ))
      {
         Bugs = $2
   
         if ( ++N >= 5 ) exit
      }
      if ( match( $1, /^microcode[\t ]*/ ))
      {
         UCode = $2
   
         if ( ++N >= 5 ) exit
      }
      if ( match( $1, /^cpu family[\t ]*$/ ))
      {
         Fam = $2 +0

         if (( ++N ) >= 5 ) exit
      }
      if ( match( $1, /^model[\t ]*$/ ))
      {
         Model = $2 +0

         if (( ++N ) >= 5 ) exit
      }
      if ( match( $1, /^stepping[\t ]*$/ ))
      {
         Step = $2 +0

         if (( ++N ) >= 5 ) exit
      }
      if ( match( $0, /^ *$/ ))
      {
         exit
      }
   }
   END {

      GotCPUId = 0

      if (( Fam > 0 ) || ( Model > 0 ) || ( Step > 0 ))
      {
        FMS = sprintf( "%02x-%02x-%02x", Fam, Model, Step )

        if (( File = GetFirmWare( IntelPath, FMS )) == "" ) File = "no firmware file for " FMS 

        printf( "CPU FMS:    %s\n", FMS )
        printf( "Firmware:   %s\n", File )

        GotCPUId = 1
      }
      print "CPU bugs:  "  Bugs
      print "Microcode: "  UCode

      exit(( GotCPUId != 0 ) ? 0 : 1 )

   }' /proc/cpuinfo

   return $?
}
#
# print interesting lines from dmesg output
#
ProcDMesg ()
{
   dmesg -t |grep -e '^microcode: CPU0 microcode updated early' \
                  -e '^Linux version'                           \
                  -e '^Command line: '                          \
                  -e '^DMI: ' |sed -e 's/  */ /g' -e 's/ ,/,/g' 

   return ${PIPESTATUS[1]}
}
#
# list the installed version of intel-microcode
#
GetUCode ()   
{
   CWD="`pwd`"
   cd /var/log/packages

   UCode="$(ls -la intel-microcode* 2>/dev/null)"

   [ "$UCode" = "" ] && UCode="intel-microcode is not installed"

   echo "UCode Pkg:  $(echo "$UCode" |ParseLsLa)"

   cd $CWD || cd -

   return
}
#
# and this is the beaver ...
#
( 
  date 
  echo "" 
  uname -a               | Tab -t2
  echo "" 
  echo "dmesg"           | Tab -t2
  ProcDMesg              | Tab -t4
  echo "" 
  echo "cpuinfo"         | Tab -t2
  GetUCode               | Tab -t4
  ProcCPUInfo            | Tab -t4
  echo "" 
  echo "vulnerabilities" | Tab -t2
  GetSMVuln              | Tab -t4
  echo ''
) |
if [ "$DoFile" != "1" ]
then
   cat
else
   tee -a $OutDir/vuln-`uname -r`.txt
fi