LinuxQuestions.org - [SOLVED] kernel 3.9.x EOL - what release kernel for Slackware 14.1?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - kernel 3.9.x EOL - what release kernel for Slackware 14.1? (https://www.linuxquestions.org/questions/slackware-14/kernel-3-9-x-eol-what-release-kernel-for-slackware-14-1-a-4175471461/)

Don't ever take what is up at kernel.org as what kernels are at face value... especially the stable kernels. Even stable kernels can have lots of bugs in them, and can be dangerous to use.

Would sticking with the last LTS branch (3.4) hold things back that much?

Quote:

Originally Posted by chicken76 (Post 5000385)

Would sticking with the last LTS branch (3.4) hold things back that much?

yes... yes... well... depends on if you have hardware that was developed after 3.4... but in that case... did I say yes already?

Quote:

Originally Posted by WhiteWolf1776 (Post 5000397)

yes... yes... well... depends on if you have hardware that was developed after 3.4... but in that case... did I say yes already?

Latest 3.10 can be in /testing as an option.
What hardware could be affected by running 3.4 ?

Newest Radeons and GeForce video cards, as well as newer AMD and Intel CPUs, might not work properly with kernel 3.4.55 as it stands.

Quote:

Originally Posted by GazL (Post 4999710)

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.

Quote:

Originally Posted by chicken76 (Post 5000385)

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.

AMD just brought out a beta catalyst driver with support for the 3.10 kernel.

Quote:

Originally Posted by chicken76 (Post 5000451)

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.

Quote:

Originally Posted by kikinovak (Post 5001350)

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.

Just my 2 cents.

Regards,

Matt

Quote:

Originally Posted by volkerdi (Post 4999762)

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?

Code:

commit f4332be72bc7a2095a21057e9db2c38bd44486b2

Author: Konstantin Khlebnikov <khlebnikov@openvz.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:

    

    commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0

    Author: Jesse Barnes <jbarnes@virtuousgeek.org>

    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:

    stable.]

    

    References https://bugs.freedesktop.org/show_bug.cgi?id=54089

    References https://bugzilla.kernel.org/show_bug.cgi?id=58971

    References https://patchwork.kernel.org/patch/2827634/ (patch v1)

    

    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>

    Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1)

    Tested-by: rocko <rockorequin@hotmail.com> (v1)

    Tested-by: JohnMB <johnmbryant@sky.com> (v1)

    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This is taken from Linux Kernel 3.10.5 ChangeLog which has just been released by Greg

Quote:

Originally Posted by sanjioh (Post 5002590)

good news! http://www.kroah.com/log/blog/2013/0...rnel-3-dot-10/

I was about to post the exact same thing. Hopefully it is not too late to switch to 3.10.x for Slackware. It is not yet even in RC status so maybe Pat will go with 3.10

LTS is not all its cracked up to be as upgrading 3.2 on 14.0 showed us last time when two nasty regressions where introduced.

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. :)