LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-31-2018, 10:54 AM   #1
HalseyTaylor
LQ Newbie
 
Registered: Aug 2018
Distribution: Slackware
Posts: 5

Rep: Reputation: Disabled
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
 
Old 08-31-2018, 12:27 PM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 10,061

Rep: Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104
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.'
 
Old 08-31-2018, 12:32 PM   #3
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
Quote:
Originally Posted by HalseyTaylor View Post
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.

Last edited by Darth Vader; 08-31-2018 at 12:52 PM.
 
2 members found this post helpful.
Old 08-31-2018, 02:32 PM   #4
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 979

Rep: Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508
@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:
Code:
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:
Code:
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
 
1 members found this post helpful.
Old 09-01-2018, 08:11 AM   #5
slalik
Member
 
Registered: Nov 2014
Location: Moscow, Russia
Distribution: Slackware
Posts: 164

Rep: Reputation: 117Reputation: 117
Quote:
Originally Posted by abga View Post
@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:
Code:
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:
Code:
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
 
Old 09-01-2018, 01:14 PM   #6
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 979

Rep: Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508
Quote:
Originally Posted by slalik View Post
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:
Code:
pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable
 
1 members found this post helpful.
Old 09-02-2018, 06:51 AM   #7
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 10,061

Rep: Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104
A P4 is still post 1995 and affected by many of the vulnerabilities. It's not that old.
 
Old 09-02-2018, 07:43 AM   #8
HalseyTaylor
LQ Newbie
 
Registered: Aug 2018
Distribution: Slackware
Posts: 5

Original Poster
Rep: Reputation: Disabled
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.
 
Old 09-02-2018, 08:43 AM   #9
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
Quote:
Originally Posted by HalseyTaylor View Post
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.

Last edited by Darth Vader; 09-02-2018 at 10:02 AM.
 
1 members found this post helpful.
Old 09-02-2018, 09:11 AM   #10
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 10,061

Rep: Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104Reputation: 1104
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.
 
Old 09-02-2018, 09:41 AM   #11
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235Reputation: 1235
Quote:
Originally Posted by business_kid View Post
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.
Attached Thumbnails
Click image for larger version

Name:	acer_veriton_l410.jpg
Views:	16
Size:	26.2 KB
ID:	28512   Click image for larger version

Name:	acer-veriton-l410-para-partes-veriton-power-supply-110v-ac-D_NQ_NP_161301-MLM20293090961_052015-.jpg
Views:	15
Size:	58.6 KB
ID:	28514  

Last edited by Darth Vader; 09-02-2018 at 12:09 PM.
 
Old 09-02-2018, 10:05 AM   #12
HalseyTaylor
LQ Newbie
 
Registered: Aug 2018
Distribution: Slackware
Posts: 5

Original Poster
Rep: Reputation: Disabled
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.

Last edited by HalseyTaylor; 09-02-2018 at 10:08 AM.
 
Old 09-02-2018, 02:51 PM   #13
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 979

Rep: Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508
Quote:
Originally Posted by HalseyTaylor View Post
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.
 
Old 09-02-2018, 02:58 PM   #14
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 979

Rep: Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508Reputation: 508
Quote:
Originally Posted by business_kid View Post
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
 
Old 09-03-2018, 06:15 AM   #15
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,483

Rep: Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916Reputation: 916
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.
Code:
# ./.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:
Code:
# ./.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.

Code:
#!/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
 
2 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
What's this error code (RC=153) etoshhy Linux - Software 8 04-26-2018 11:19 PM
LXer: News: Linux Top 3: Tails 1.2.3, Steam OS Update 153 and Linux Mint systemd LXer Syndicated Linux News 0 01-21-2015 07:00 PM
Deepin Update is Dead Slow. Can I use Ubuntu Update? yurmuki Linux Deepin 7 07-15-2014 11:41 AM
LXer: Softpedia Linux Weekly, Issue 153 LXer Syndicated Linux News 0 06-26-2011 01:10 PM
mirrors slow to update? fancylad Slackware 6 03-07-2010 04:43 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:00 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration