SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.'
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.
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.
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:
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:
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.
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.
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.
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.
Last edited by Darth Vader; 09-02-2018 at 12:09 PM.
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.
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.
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.