LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-30-2013, 09:53 AM   #1
mattallmill
Member
 
Registered: Nov 2009
Location: Salina,Kansas
Distribution: Slackware64-current
Posts: 201

Rep: Reputation: 31
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.

Regards,

Matt
 
Old 07-30-2013, 10:49 AM   #2
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 2,546

Rep: Reputation: 419Reputation: 419Reputation: 419Reputation: 419Reputation: 419
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
 
Old 07-30-2013, 11:36 AM   #3
GazL
Senior Member
 
Registered: May 2008
Posts: 3,365

Rep: Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899
These two (fixed in 3.10.4) sound quite scary. Not sure I'd be comfortable running 3.9 on anything important if these remain un-patched.

Quote:
commit c07ae685f761d7b6850f502a34964005428c181a
Author: Theodore Ts'o <tytso@mit.edu>
Date: Mon Jul 15 00:09:19 2013 -0400

ext4: fix error handling in ext4_ext_truncate()

commit 8acd5e9b1217e58a57124d9e225afa12efeae20d upstream.

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.


Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quote:
commit 9fa65e09730a2e63c5b45d008f269b2b271b74bc
Author: Jan Kara <jack@suse.cz>
Date: Fri Jun 28 16:04:02 2013 +0200

writeback: Fix periodic writeback after fs mount

commit a5faeaf9109578e65e1a32e2a3e76c8b47e7dcb6 upstream.

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.
 
Old 07-30-2013, 11:50 AM   #4
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 801

Rep: Reputation: 157Reputation: 157
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.
 
Old 07-30-2013, 11:52 AM   #5
mattallmill
Member
 
Registered: Nov 2009
Location: Salina,Kansas
Distribution: Slackware64-current
Posts: 201

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by GazL View Post
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.

Regards,

Matt
 
3 members found this post helpful.
Old 07-30-2013, 12:17 PM   #6
GazL
Senior Member
 
Registered: May 2008
Posts: 3,365

Rep: Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899
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.
 
3 members found this post helpful.
Old 07-30-2013, 12:19 PM   #7
GazL
Senior Member
 
Registered: May 2008
Posts: 3,365

Rep: Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899Reputation: 899
Quote:
Originally Posted by mattallmill View Post
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.
Yes, I found out the hard-way as well.
 
1 members found this post helpful.
Old 07-30-2013, 12:20 PM   #8
Timothy Miller
Member
 
Registered: Feb 2003
Location: Arizona, USA
Distribution: Debian Jessie, OpenSuse 13.1, Chakra.
Posts: 665

Rep: Reputation: 95
Quote:
Originally Posted by mattallmill View Post
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.
 
Old 07-30-2013, 12:21 PM   #9
mattallmill
Member
 
Registered: Nov 2009
Location: Salina,Kansas
Distribution: Slackware64-current
Posts: 201

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by GazL View Post
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.
Totally agree.
 
Old 07-30-2013, 01:22 PM   #10
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 861

Rep: Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680Reputation: 1680
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.
 
9 members found this post helpful.
Old 07-30-2013, 04:19 PM   #11
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-14.1 (3.16.0) UEFI enabled
Posts: 348

Rep: Reputation: 71
3.10.0 3.10.1 3.10.2 3.10.3 3.10.4

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
 
Old 07-30-2013, 04:40 PM   #12
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 2,546

Rep: Reputation: 419Reputation: 419Reputation: 419Reputation: 419Reputation: 419
NVidia proprietary driver works for me on Linux Kernel 3.10.x, but the author of the patch said it was really an ugly patch, but it does work
 
Old 07-30-2013, 04:51 PM   #13
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 1,739

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
Quote:
Originally Posted by mattallmill View Post
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!
 
Old 07-30-2013, 04:53 PM   #14
cwizardone
Senior Member
 
Registered: Feb 2007
Distribution: Slackware64-current & "True Multilib." PC-BSD.
Posts: 2,229

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by GazL View Post
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.
 
Old 07-30-2013, 08:31 PM   #15
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,950

Rep: Reputation: Disabled
Quote:
Originally Posted by GazL View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Linux Kernel 3.8 Reaches End of Life (EOL) LXer Syndicated Linux News 0 05-13-2013 02:12 PM
LXer: Kernel Comment: Release early, release often! LXer Syndicated Linux News 0 08-31-2012 04:10 PM
Notice of Impending EOL (end of life) for old Slackware versions comet.berkeley Slackware 8 07-14-2012 03:16 PM
EOL Slackware-10.1 thenob Slackware 2 04-02-2010 02:07 AM


All times are GMT -5. The time now is 03:28 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration