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.
It certainly is a bit odd that on this very page we see update releases for kernels as old as 3.6.x and as new as 5.7.x. It seems like "back in the day" we hung out at 2.6.x kernels almost exclusively for a very long time. How do people choose these days? I'm currently using 5.5.12 and if I understand correctly the 5.5.x branch was done and abandoned shortly after. I like 5.5.12 and had planned to upgrade when 5.5.20 was released but apparently that's a dead end. What compelling reason is there to go to 5.6.x? Is there some perceived issue with 5.5.x that can't easily be handled by a revision?
It certainly is a bit odd that on this very page we see update releases for kernels as old as 3.6.x and as new as 5.7.x. It seems like "back in the day" we hung out at 2.6.x kernels almost exclusively for a very long time. How do people choose these days? I'm currently using 5.5.12 and if I understand correctly the 5.5.x branch was done and abandoned shortly after. I like 5.5.12 and had planned to upgrade when 5.5.20 was released but apparently that's a dead end. What compelling reason is there to go to 5.6.x? Is there some perceived issue with 5.5.x that can't easily be handled by a revision?
The 2.6.x.x kernels were versioned much differently than the modern kernels. 3.x-5.x could essentially be considered 2.8.x.x style kernels.
The way the current kernel development works is to EOL one version the month after the next version is released (with exception to LTS releases). This ensures developers are only adding features to the mainline (their version of -current) and fixes are only going to the latest released kernel (with exception for any needed fixes for LTS kernels).
So, if we start off with the 5.3 version, it was released in Sep 2019. 5.2 was EOL'd Oct 2019. Then 5.4 was released Nov 2019, so 5.3 was EOL'd Dec 2019. 5.5 was released in Jan 2020, but 5.4 is an LTS, so it has not been EOL'd. Now we've had 5.6 released in Mar 2020, so 5.5 was EOL'd this month.
Basically, if you don't want to stick with an LTS version, once the next kernel version is released, expect the previous to be EOL'd the following month.
I mostly stick with LTS kernels unless there's something big in a newer one that I'm itching to have
In days of yore, I always compiled my own kernels, tailored to the specific hardware they would run on. In recent years, I seem to have collected a small bunch of machines that all have differing hardware. This has made tailoring kernels for each bit of hardware time consuming, added to which kernels have become increasingly large and seem to take longer to compile.
So for the last few years, I've been using the "stock" Slackware kernels. I'm running -current + AlienBob's Plasma5 because 14.2/kde4 no longer support many of the apps I use most. However, I am having issues with the 5.4.X series kernels, LTS or not. It mostly centers around the i915 drivers.
Although the stock 5.4.X kernels work fine on most of my hardware, my main desktop machine has a TBS DVB card built in, which I use quite a bit as a home DVR. Unfortunately, the TBS driver breaks the i915 driver included in 5.4.X kernels, rendering the machine unusable.
In desperation, I compiled 5.6.7, using the .config file from 5.4.35, and leaving all new settings at their default values. I can now successfully build and run the TBS drivers again!
Searching t'internet, I find lots of references to issues with the i915 driver in 5.4.X kernels, including indications that these are never likely to be fixed. I would have said that I find the latter statements unrealistic, but in my experience, the issue has been present for at least ten iterations of the 5.4.X kernel, without being solved.
Many laptops - and indeed my desktop - come with integrated Intel graphics, which is more than adequate for my purposes - and indeed better, in some respects, than AMD or NVidia for pure video work. It seems unlikely, therefore, that I'm the only one running into this issue, and indeed googling for it confirms my suspicions!
I will be mightily glad when 15 is finally released, and hopefully some non-LTS kernels find their way into "Testing".
We're working on trying to figure out a severe performance regression in
the 5.4 and older LTS trees. The regression seems to happen only on
physical spinning rust disks, which is why it was probably went
unnoticed.
The regression seems to be introduced in v4.7 with:
1f60fbe72749 ("ext4: allow readdir()'s of large empty directories to be interrupted")
Many laptops - and indeed my desktop - come with integrated Intel graphics, which is more than adequate for my purposes - and indeed better, in some respects, than AMD or NVidia for pure video work. It seems unlikely, therefore, that I'm the only one running into this issue, and indeed googling for it confirms my suspicions!
A few years ago I bought a little laptop for general office use. I put Slackware 14.2 on it. At the time, I had no idea of the video related troubles in store, but I found out, and became well acquainted with the i915 driver. At first I thought the trouble was a configuration fault of mine, but it was found (by the Linux Questions group working with me on it) that the trouble was actually the i915 driver. One of our group informed the kernel maintainers of a particular problem, and before long the fix was backported from the newer kernels to the LTS 4.4.x series. This did fix a big problem, but then the little laptop ran long enough that another problem came to light: an interrupt conflict between the video card and the network card. This problem only caused a fault when I ran the GUI. After a few years of butting heads with the i915 driver, I decided to demote the little laptop from general office use to being the DNS server for my home network.
So, I bought a different little laptop which does not have a video card which requires the i915 driver --> and it has been great!
baumei.. yeah I'm pretty sure my next laptop will not have an Intel GPU for this very reason. AMD Ryzen 4000 series laptops look like the perfect fit these days...
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,107
Original Poster
Rep:
Year 2020, Round 29
Another batch of kernel updates has been scheduled for release on Sunday, 03 May 2020, at approximately 13:00, GMT. If no problems are found while testing the release candidates, they might be available late Saturday or early Sunday (depending on your time zone).
There will be 106 patches in the 5.6.9 update, 83 in 5.4.37, 46 in 4.19.120, 117 in 4.14.178, 80 in 4.9.221 and, finally, 70 patches in the 4.4.221 update.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,107
Original Poster
Rep:
A second round of release candidates has been announced for the 4.19.120, 4.14.178, 4.9.221 and 4.4.221 kernel updates. They are now scheduled for release on Monday, 04 May 2020, at approximately 06:30 GMT.
Revert "ASoC: meson: axg-card: fix codec-to-codec link setup"
This reverts commit 005aa9f0af9d600d3c8fa655a4aa48e4ec7c5b9d which is
commit 1164284270779e1865cc2046a2a01b58a1e858a9 upstream.
It should not have been backported, I only looked at the "Fixes:" tag,
not the changelog text itself, my fault.
I got my kernels done before I went to bed this morning and thought... that was rather quick of them to push these out, maybe I should wait and it'll be 5.6.10 later. Sure enough.
I'm betting that's not a driver most people would compile. There's no need for me to rebuild.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
