[SOLVED] kernel 3.9.x EOL - what release kernel for Slackware 14.1?
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.
kernel 3.9.x EOL - what release kernel for Slackware 14.1?
I just saw the note by Greg Kroah-Hartman on lkml saying that the 3.9.x kernel is EOL and that we should upgrade to 3.10.x.
My question concerns the release kernel for Slackware 14.1. If 3.9.x will not be receiving updates of any kind, will it be suitable for a release kernel? I am, of course, upgrading to 3.10.4 as I type, but I am a bit concerned about the upcoming release.
If anyone knows anything about this, please let me know. Thanks.
Pat has placed a config file for 3.10.x in testing
you can use the SlackBuild script from the source directory combined with the config file in testing to build the new kernel
Previously ext4_ext_truncate() was ignoring potential error returns
from ext4_es_remove_extent() and ext4_ext_remove_space(). This can
lead to the on-diks extent tree and the extent status tree cache
getting out of sync, which is particuarlly bad, and can lead to file
system corruption and potential data loss.
Code in blkdev.c moves a device inode to default_backing_dev_info when
the last reference to the device is put and moves the device inode back
to its bdi when the first reference is acquired. This includes moving to
wb.b_dirty list if the device inode is dirty. The code however doesn't
setup timer to wake corresponding flusher thread and while wb.b_dirty
list is non-empty __mark_inode_dirty() will not set it up either. Thus
periodic writeback is effectively disabled until a sync(2) call which can
lead to unexpected data loss in case of crash or power failure.
Fix the problem by setting up a timer for periodic writeback in case we
add the first dirty inode to wb.b_dirty list in bdev_inode_switch_bdi().
Reported-by: Bert De Jonghe <Bert.DeJonghe@amplidata.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reports on 3.10 seem mixed, and it has had a hell of a lot of patches for what was supposed to be a 'Stable' release -- which always makes me wary. The nvidia drivers don't work with it either (unless you're happy to risk 3rd party patches that do god only knows what to it).
Tricky one. I'm going to have to think on this a bit.
Kernel versions get EOL'd pretty fast these days. 3.9 was released on April 29 and is now EOL. 3.10 was released on June 30, and 3.11 is already on RC3. It seems quite likely that 3.10 could be declared EOL before 14.1 ships. Whatever kernel is chosen for 14.1, unless it is an LTS kernel, is likely to be EOL before or shortly after the Slackware release.
How important is it that a new Slackware release ship with a kernel that isn't already EOL on the release date? Unless it's an LTS kernel, the shipped kernel version is going to be EOL before long anyway.
The nvidia drivers don't work with it either (unless you're happy to risk 3rd party patches that do god only knows what to it).
Tricky one. I'm going to have to think on this a bit.
Apparently, the AMD drivers don't work with it either. I just discovered this unpleasantness after setting everything else up (making an initrd image for 3.10.4, uninstalling the AMD driver, etc.), and spent the better part of an hour reverting everything back to where it was. It would have been nice if I had known beforehand that the drivers were incompatible with 3.10.x before trying to upgrade.
What you said about the security issues do concern me, but the AMD driver's incompatibility concerns me more. I'm sticking with 3.9.10 until the release of new AMD drivers which fix this issue.
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.
To be frank, I'm starting to get a little disillusioned with the kernel development process. If the "Stable" kernels really need this amount of patching post release, then clearly they weren't ready when the .0 was pushed out the door, and they come so thick and fast you've hardly had time to compile and install it before there's another one waiting to be built.
The development model of the linux kernel really doesn't help matters. Sometimes there just doesn't seem to be a good option, and I don't envy Pat having to try and navigate this minefield.
I just discovered this unpleasantness after setting everything else up (making an initrd image for 3.10.4, uninstalling the AMD driver, etc.), and spent the better part of an hour reverting everything back to where it was. It would have been nice if I had known beforehand that the drivers were incompatible with 3.10.x before trying to upgrade.
Apparently, the AMD drivers don't work with it either. I just discovered this unpleasantness after setting everything else up (making an initrd image for 3.10.4, uninstalling the AMD driver, etc.), and spent the better part of an hour reverting everything back to where it was. It would have been nice if I had known beforehand that the drivers were incompatible with 3.10.x before trying to upgrade.
What you said about the security issues do concern me, but the AMD driver's incompatibility concerns me more. I'm sticking with 3.9.10 until the release of new AMD drivers which fix this issue.
Regards,
Matt
Same boat here. I actually upgraded one of my systems to 3.10.something before I found out that proprietary drivers don't work with it. Was going nuts trying to figure out why I couldn't get the drivers to work until I started reading.
Also will be sticking with 3.9.x until Nvidia and AMD have their drivers working with it, since most of my machines have one or the other.
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.
To be frank, I'm starting to get a little disillusioned with the kernel development process. If the "Stable" kernels really need this amount of patching post release, then clearly they weren't ready when the .0 was pushed out the door, and they come so thick and fast you've hardly had time to compile and install it before there's another one waiting to be built.
The development model of the linux kernel really doesn't help matters. Sometimes there just doesn't seem to be a good option, and I don't envy Pat having to try and navigate this minefield.
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.
What I do think should almost be considered official policy is that the proprietary video drivers are on their own. Holding the kernel back for those should really only happen if there's nothing else to gain by moving to a newer branch. So, once the decision becomes should we keep the video drivers working, or fix the power bug, I'll be strongly inclined to just move forward unless other drawbacks can be pointed out. What we know is that any particular branch (unless LTS, which is becoming increasingly rare) will move quickly towards EOL, so the important thing is to pick the most bug-free branch. The video drivers can always be expected to catch up to whatever kernel is chosen, and in the case of 3.10.x more than likely by the time discs would ship.
Having the default .configs demonstrate the CONFIG_BINFMT_SCRIPT=y will also prevent a lot of people trying to update to a newer kernel from falling into that trap and being unable to boot.
just a quick me-too on the video problems
they are not only with the propietary drivers
"""
Linux kernel: [ 534.465167] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
"""
Also having crashes with resume from S3
I have been trying a patch from Tomas Winkler, but no cigar so far.
For me this is what makes computers fun, but only after the problems are solved
LOL
I'm sure it is a tough call for Pat.
john
EDIT ONE CAVEAT
The crashes are occurring when running slack14.0 with 3.10 configured with the current/testing/config
This same kernel configuration seems to run fine in current. so far so good
IMPORTANT
The crash has now also occurred in current it just took a little longer
Last edited by AlleyTrotter; 08-02-2013 at 09:47 AM.
Reason: new crash info
I just discovered this unpleasantness after setting everything else up (making an initrd image for 3.10.4, uninstalling the AMD driver, etc.), and spent the better part of an hour reverting everything back to where it was. It would have been nice if I had known beforehand that the drivers were incompatible with 3.10.x before trying to upgrade.
I would have followed the same path later today if I had not read this... think I'll wait - thanks!
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,086
Rep:
Quote:
Originally Posted by GazL
Yes, I found out the hard-way as well.
+1.
None of the kernels from 3.9.4 through 3.10.4 fix the audio volume problem I've had and now the video glitch. I'm sticking with the 3.8.13 kernel until something better comes along.
Last edited by cwizardone; 07-30-2013 at 04:56 PM.
To be frank, I'm starting to get a little disillusioned with the kernel development process. If the "Stable" kernels really need this amount of patching post release, then clearly they weren't ready when the .0 was pushed out the door, and they come so thick and fast you've hardly had time to compile and install it before there's another one waiting to be built.
There's been quite a few reverts in the last few releases as well, and that's never a good sign. Nothing really major (perhaps some laptop users would disagree), but enough to make me feel slightly uneasy about upgrading to the very latest release.
I'll be studying the changelogs extra carefully from now on, and I will probably stay clear of releases with patches that seem overly clever and affect critical subsystems.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
