[SOLVED] kernel 3.9.x EOL - what release kernel for Slackware 14.1?
SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Whether it is EOL really isn't the issue: the important consideration is what known bugs are lurking unfixed within it. Most won't matter, but those that either have security implications, or will eat your data need to be considered/addressed, especially so as many people will stick with whatever kernel Pat ships.
Hit the nail on the head. Looking to "LTS" kernels or non-EOL'd kernels is a red herring. The question is, is it stable and secure while supporting as much modern hardware as possible. Going with something other than a bleeding-edge kernel is a prerequisite to this as only time can tell whether a kernel release will prove stable.
Security issues may arise -- 3.2.29 was upgraded to 3.2.45 due to a critical security fix, for example. But entire release cycles of Slackware have passed by without a single kernel upgrade required. Patrick Volkerding has already said in a previous thread that he will backport serious security issues if needed. It was pretty lucky that an uber-LTS kernel like 3.2 happened to be reasonably modern at the time 14.0 came out, as it made the security issue relatively straightforward to resolve, but that can't be relied upon for future releases in my view.
Would sticking with the last LTS branch (3.4) hold things back that much?
I have no problem holding back all the way to 3.2 (used in the last slackware release) if it was best for everyone. There is no reason to move to any later version if it is detrimental to overall usability, including those that are so called 'LTS'. It has happened with slackware releases before where a program version was not moved.
I will probably be on 3.6 or later kernel to use some new wireless drivers. I am currently testing 3.10. If it weren't for that, I probably would consider 3.2 / sticking with older slackware installs. These newer kernels make me very nervous from what I've been seeing lately -- the LTS maintainership and userspace stuff among the items. So there is not much for me wanting to see an "advancement" to 3.9/3.10 except for hopefully fixing the troubling items that plague people. I think that is where we are at. I'm on-board as much as it really helps the most people as possible.
Latest 3.10 can be in /testing as an option.
What hardware could be affected by running 3.4 ?
There have been some new wifi and audio drivers, hybrid graphics support that might matter for some laptops, and a lot of ARM stuff. If I remember correctly, 3.7 or so fixed the screen brightness controls on my Zenbook. I can't think of it right now, but I also thought there was something power management wise . . . but maybe I'm just thinking of the support for Intel's rc6 feature that was worked into 3.4. That one was important for me, because I had very poor battery life on my laptop and was looking at everything that could fix it.
AMD just brought out a beta catalyst driver with support for the 3.10 kernel.
Since no one else has reported back on this beta driver, I'm going to do so, having downloaded and installed it.
It installed without incident, and now I'm running on the 3.10.4 kernel with the AMD proprietary driver. All I have to say on the matter is that it took AMD long enough to catch up. I think that the Radeon chips, by themselves, are not bad. It's the state of the drivers, and AMD's lethargic development process which makes owning a Radeon distasteful to most people.
Anyway, I am pleased with the results, and plan on staying (now) with 3.10.x.
Yeah, this is a tough one. But at this point I'm almost leaning towards bumping to 3.10.x. If the Sandy Bridge power issue on resume were patched there, I'd have probably done so already. So far the patch hasn't shown up outside of the 3.11 tree, though.
Is this what you waited for?
Author: Konstantin Khlebnikov <firstname.lastname@example.org>
Date: Wed Jul 17 10:22:58 2013 +0400
drm/i915: fix long-standing SNB regression in power consumption after resume v2
commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream.
This patch fixes regression in power consumtion of sandy bridge gpu, which
exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
it's extremely busy. After that it never reaches rc6 state.
Bug exists since kernel v3.6:
Author: Jesse Barnes <email@example.com>
Date: Thu Jun 14 11:04:48 2012 -0700
drm/i915: load boot context at driver init time
For some reason RC6 is already enabled at the beginning of resuming process.
Following initliaztion breaks some internal state and confuses RPS engine.
This patch disables RC6 at the beginnig of resume and initialization.
I've rearranged initialization sequence, because intel_disable_gt_powersave()
needs initialized force_wake_get/put and some locks from the dev_priv.
Note: The culprit in the initialization sequence seems to be the write
to MBCTL added in the above mentioned commit. The first version of
this patch just held a forcewake reference across the clock gating
init functions, which seems to have been enought to gather quite a few
positive test reports. But since that smelled a bit like ad-hoc
duct-tape v2 now just disables rps/rc6 across the entire hw setup.
[danvet: Add note about v1 vs. v2 of this patch and use standard
layout for the commit citation. Also add the tested-bys from v1 and a cc:
References https://patchwork.kernel.org/patch/2827634/ (patch v1)
Signed-off-by: Konstantin Khlebnikov <firstname.lastname@example.org>
Tested-by: Alexander Kaltsas <email@example.com> (v1)
Tested-by: rocko <firstname.lastname@example.org> (v1)
Tested-by: JohnMB <email@example.com> (v1)
Signed-off-by: Daniel Vetter <firstname.lastname@example.org>
Signed-off-by: Greg Kroah-Hartman <email@example.com>
This is taken from Linux Kernel 3.10.5 ChangeLog which has just been released by Greg
I'm still testing 3.8.13 with 14.0 on my newer machines (the older ones stay with 3.2.29). It works fine, is stable and compatible with all this 3rd party stuff I need. I still think, it would make a good default kernel choice for the next release.
As for 3.10: I tend to stay away from kernels with single-digit-patchlevels. I will look into it, once it reaches 3.10.23 or so.