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.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,166
Original Poster
Rep:
AMD users, especially, may find this to be of interest:
Quote:
Linux 5.10.17 Backports CPUFreq Patches From 5.11 - Benchmarks
Written by Michael Larabel in Linux Kernel on 18 February 2021 at 07:27 AM EST.
LINUX KERNEL --
Released yesterday was the Linux 5.10.17 LTS kernel and what makes this point release a bit more notable than usual is that it backports the CPUFreq patches from 5.11 that were used for addressing the earlier AMD performance regression on Linux 5.11 and often leading to net improvements as well over prior kernel series. The CPUFreq patches were back-ported while the AMD frequency invariance support was not, so what does the performance look like for the Linux 5.10 LTS kernel? Here are some benchmarks.......
5.11.0 built and runs without problem on Slackware64-current
Had some issues on 14.2. After some investigation I found the recipe for
'drivers/idxd/submit.o' fails on the config I was using which had it set as a module. Seems it was building as a module in the 5.10 series also, however my system does not seem to use it. I reset it to no (IE is not set) in .config and everything builds and works as expected.
I love it when things go astray, gives me something to work on.
HTH
john
Thank you. Today I gave 5.11 another shot, after giving up around rc 2 or 3, and the results were an epic fail as before. So I disabled CONFIG_INTEL_IDXD based on this post, and it all compiled and installed fine. Testing now, but so far so good.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,166
Original Poster
Rep:
FWIW, since installing the 5.10.17 kernel this box has locked up solid twice.
In both cases mozilla-firefox-78.7.1esr-x86_64-1 was running and I had moved from it to do someething else. The first time I had been streaming video in Firefox. The second time I had been reading the headlines on a news site. Thunderbird is almost always running in the background.
I've reverted to 5.10.16 and we'll see how it goes.
Last edited by cwizardone; 02-19-2021 at 01:33 PM.
Reason: Typo.
FWIW, since installing the 5.10.17 kernel this box has locked up solid twice.
In both cases mozilla-firefox-78.7.1esr-x86_64-1 was running and I had moved from it to do someething else. The first time I had been streaming video in Firefox. The time I had been reading the headlines on a news site. Thunderbird is almost always running in the background.
I've reverted to 5.10.16 and we'll see how it goes.
Thursday's changelog for current x64
Quote:
Thu Feb 18 20:47:35 UTC 2021
xap/mozilla-firefox-78.7.1esr-x86_64-1.txz: Upgraded.
It looks like rebuilding Firefox with Rust 1.50.0 causes it to crash on
HTML5 streams, so let's drop back to this build. 78.8.0 is coming soon
and hopefully it'll fix this.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,166
Original Poster
Rep:
Quote:
Originally Posted by truepatriot76
Thursday's changelog for current x64
Yes, check the version number in my post.
Mr. Volkerding was reverting from mozilla-firefox-78.7.1esr-x86_64-2
back to mozilla-firefox-78.7.1esr-x86_64-1, which was an uppdate from 5 February.
CC [M] drivers/infiniband/hw/hfi1/opfn.o
CC [M] drivers/infiniband/hw/hfi1/pcie.o
CC [M] drivers/infiniband/hw/hfi1/pio.o
CC [M] drivers/infiniband/hw/hfi1/pio_copy.o
CC [M] drivers/infiniband/hw/hfi1/platform.o
CC [M] drivers/infiniband/hw/hfi1/qp.o
CC [M] drivers/infiniband/hw/hfi1/qsfp.o
CC [M] drivers/infiniband/hw/hfi1/rc.o
CC [M] drivers/infiniband/hw/hfi1/ruc.o
CC [M] drivers/infiniband/hw/hfi1/sdma.o
CC [M] drivers/infiniband/hw/hfi1/sysfs.o
CC [M] drivers/infiniband/hw/hfi1/tid_rdma.o
CC [M] drivers/infiniband/hw/hfi1/trace.o
CC [M] drivers/infiniband/hw/hfi1/uc.o
CC [M] drivers/infiniband/hw/hfi1/ud.o
CC [M] drivers/infiniband/hw/hfi1/user_exp_rcv.o
CC [M] drivers/infiniband/hw/hfi1/user_pages.o
CC [M] drivers/infiniband/hw/hfi1/user_sdma.o
CC [M] drivers/infiniband/hw/hfi1/verbs.o
CC [M] drivers/infiniband/hw/hfi1/verbs_txreq.o
CC [M] drivers/infiniband/hw/hfi1/vnic_main.o
CC [M] drivers/infiniband/hw/hfi1/vnic_sdma.o
CC [M] drivers/infiniband/hw/hfi1/debugfs.o
LD [M] drivers/infiniband/hw/hfi1/hfi1.o
Makefile:1800: recipe for target 'drivers' failed
make: *** [drivers] Error 2
mv: cannot stat '/tmp/kernel-source-5.11.0-noarch-1.txz': No such file or directory
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,018
Rep:
Quote:
Originally Posted by PROBLEMCHYLD
5.11 won't build
CC [M] drivers/infiniband/hw/hfi1/opfn.o
CC [M] drivers/infiniband/hw/hfi1/pcie.o
CC [M] drivers/infiniband/hw/hfi1/pio.o
CC [M] drivers/infiniband/hw/hfi1/pio_copy.o
CC [M] drivers/infiniband/hw/hfi1/platform.o
CC [M] drivers/infiniband/hw/hfi1/qp.o
CC [M] drivers/infiniband/hw/hfi1/qsfp.o
CC [M] drivers/infiniband/hw/hfi1/rc.o
CC [M] drivers/infiniband/hw/hfi1/ruc.o
CC [M] drivers/infiniband/hw/hfi1/sdma.o
CC [M] drivers/infiniband/hw/hfi1/sysfs.o
CC [M] drivers/infiniband/hw/hfi1/tid_rdma.o
CC [M] drivers/infiniband/hw/hfi1/trace.o
CC [M] drivers/infiniband/hw/hfi1/uc.o
CC [M] drivers/infiniband/hw/hfi1/ud.o
CC [M] drivers/infiniband/hw/hfi1/user_exp_rcv.o
CC [M] drivers/infiniband/hw/hfi1/user_pages.o
CC [M] drivers/infiniband/hw/hfi1/user_sdma.o
CC [M] drivers/infiniband/hw/hfi1/verbs.o
CC [M] drivers/infiniband/hw/hfi1/verbs_txreq.o
CC [M] drivers/infiniband/hw/hfi1/vnic_main.o
CC [M] drivers/infiniband/hw/hfi1/vnic_sdma.o
CC [M] drivers/infiniband/hw/hfi1/debugfs.o
LD [M] drivers/infiniband/hw/hfi1/hfi1.o
Makefile:1800: recipe for target 'drivers' failed
make: *** [drivers] Error 2
mv: cannot stat '/tmp/kernel-source-5.11.0-noarch-1.txz': No such file or directory
can you try to build kernel from the sources? Just copy your config file from the previous version of the working kernel and compile/build. I never used Slackware kernel scripts but it looks like you don't have requested file/folder in /tmp
It was my fault. I added the latest Bluetooth patch which doesn't work so I used the older patch and everything is fine. Kernel Devs are suppose to fixed the BT issues in 5.10.18 and 5.11.1. I will be testing 5.11.0 until 5.11.10 comes out.
It would be interesting to know why.
Hmmmm.... the 5.10.y series had been sort of a dog.....
Maybe the common sense finally prevailed and our BDFL decided to stop cursing our boxes with those industrial kernels which Intel, Radeon or even Nouveau users does not need at all?
Honestly, I believe that IF Mr. Volkerding have pity for the blob worshipers, he can put an industrial kernel on /extra and leave us others to enjoy the latest features given by Mr. Linus Torvalds, instead of some antic kernels older than my grandpa who fought on Stalingrad Battle...
Last edited by LuckyCyborg; 02-20-2021 at 05:45 PM.
I can confirm the Nvidia-460.39 driver does install correctly with the 5.11.0 kernel.
OTOH, VirtualBox will not install, but, so far, everything else is working correctly.
Maybe the common sense finally prevailed and our BDFL decided to stop cursing our boxes with those industrial kernels which Intel, Radeon or even Nouveau users does not need at all?
Honestly, I believe that IF Mr. Volkerding have pity for the blob worshipers, he can put an industrial kernel on /extra and leave us others to enjoy the latest features given by Mr. Linus Torvalds, instead of some antic kernels older than my grandpa who fought on Stalingrad Battle...
It has had nothing to do with "blob worshipers". It was always about long term support so Pat could provide updates without pushing new kernels that could break stability (just look at the update from 5.4.x to 5.10.x... it's been fine for some, and severely broken for others). Pat has been able to provide updates for the 4.4 kernel for many years now.
Pat has broken blob drivers many times over the years by putting in a kernel or Xorg that wasn't supported by those blobs, so don't think him sticking with LTS kernels was to appease people using binary drivers.
However, we are definitely in new grounds with having a non-LTS kernel in testing/ and we'll have to see how things play out.
Basically just a ME-TO but I've been running 5.11.0 on both current and 14.2 for several days without issue
CAUTION
What works for me may not work for thee.
HTH
john
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
