Linux Kernel 2.2.13 Makes the Scene
Mads-Martin was one of the many folks to point out that 2.2.13 has made the mirrors. The patch is also up on kernel.org. You know the routine - download, compile, etc.
← Back to Stories (view on slashdot.org)
Look to the kernelnotes site for more details. I expect the changes list will appear there first....
Since Alan Cox have been taking over the 2.2 kernel branch, there's lot of good info about it at www.uk.linux.org and at his diary.
Can we please not post kernel releases unless the change log is also attached? Without this, I fear that we are pushing the "you must upgrade" mentality that MS users are used to. This way, we may also help cut down on the number of downloads that are done and free up some bandwidth for those people that may actually need the fix.
(I've had no problems with kernels up to 2.2.12, with assorted patches, so I'm going to give 2.2.13 a try with 2.95.1. :)
Depending on when/how the error occurs, you might want to make -every- non-essential option that you want into an option, where "non-essential" includes anything not absolutely needed to boot the OS. I can't promise that'll fix anything, but it might just coax the kernel into booting, by using less memory, to start with.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
From what I understand, 2.95 (not 2.95.1) has some serious bugs, which can cause some spectacular roll & burns with the kernel. I've not seen any bugs -definitely- attributable to the compiler, so far. However, I -have- seen some quirky behaviour when trying to get Linux 2.3.xx kernels working, which -may- be compiler glitches, or may simply be a result of my habit of compiling with very high optimiser flags.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
A while ago somebody posted in the gcc 2.95 announcement article that all you had to do to get the kernel compiled fine with 2.95(.1) was add -fno-strict-aliasing to the CFLAGS in the Makefile - it works fine for me, I've been running 2.2.13 compiled with gcc 2.95.1 since a few hours now.
Here's the gcc 2.95 story, it's comment #26.
For what it's worth, I've been able to compile and use the 2.3.x series with gcc 2.95.1, and that's even with freaky opt flags like -O6 -mpentium. This is in distinct contrast to pgcc 2.95.1, which could best be described as a Signal 11 generator instead of a compiler.
---------------------
---------------------
John 3:16 - God's Public License
When 2.2.11 there was an issue that I had mentioned here; It was as follows. If you have a fresh 2.2.11 you could apply the 2.2.12 patch right on top of it, however if you had applied any of the patches to 2.2.11 (in my case the tcp/ip fix -> they are found at www.linux.org.uk) then you had to revert the patch or start out with a clean 2.2.11 or just download the 2.2.12.
My question now is: for 2.2.12 there was a patch for a slow page leak which I just applied. This patch actually reverted part of the 2.2.12 patch. Do I now need to re apply this patch and then apply the 2.2.13 patch or can I just patch my system with the 2.2.13 patch?
My best guess: from my past experience I am going to guess to say that I must apply the reverted patch to 2.2.12 and then apply the patch to 2.2.13. Or start out with a fresh 2.2.12 and patch to 2.2.13 or just download the whole 2.2.13.
Although having a new kernel out is good news as I am sure it has fixes and new featuress, I am not sure it is necessary for me to upgrade. Also something to add here is that according to the linux kernel howto (last time I read it atleast) they suggested that upgrading the kernel is only done if you need some feature or bug fix in a newer kernel.
hmm Maybe I'll wait this time and see if there are bugs in there that will affect me. Besides 13 is not the luckest number.-> If you believe in superstition ;-0
Only 'flamers' flame!
NCC (Nature's C Compiler) does support the -superstition flag, but this is turned off by default, if you also use -geek. You can override this, by selecting -spooky. However, -spooky cannot be used with any debug flags and will automatically disable any reality exception handlers.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I totally agree with your point!
:) that have this (stupid) thing about having the "latest" update before our peers. OK, I acknowledge that this is stupid. But we only do this for non-mission critical machines, so it is all out of fun. I don't update any of our critical machines unless the change log acknowledges a change that directly (or indirectly) affects us.
/. keep posting as soon as it comes out. It doesn't hurt. Those of use that want the "latest" no matter what will be happy, and those who are interested in the change logs can wait for them. I sit on both sides of the ladder.
But...
There's some of us (I'm included
So, please
Steven Rostedt
Steven Rostedt
-- Nevermind
I'm not going to show my computer those release notes. The kernel's quite happy, with being built with pgcc 2.95.1, with numerous patches & extensions, and I don't want to scare it. :) Especially with Halloween around the corner. :)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
0 1 - just my two bits
Actually, the more I look at this, the more annoying it is. There are no release notes anywhere. I've looked at cutting edge, kernelnotes, Alan's site. No one claims to even know that 2.2.13 *is*.
Is this supposed to prevent people from addopting 2.2.13 too fast? What's the deal? I really should not have to read the development mailing list archives to find out what the latest "stable" kernel does.
That said, I can see the other side of the coin. Most of the people who should upgrade are those who have specific problems, and their vendors will direct them to the new version.... I dunno, it just seems odd. What do others think?
NCC (Nature's C Compiler) does no longer support -geek (it's deprecated), the new version (NCC 3.15.6) now uses the -nerd flag which turns off -superstition (just like version 3.14.8) but turns on the -mustreadslashdot12timesaday flag (this is new for version 3.15.6)
furthermore, there is a new -microsoftslave flag (which disables the -nerd flag) and a new -linuxnerd flag (which enables -nerd , -mustreadslashdot12timesaday and -hateMS )
---
from 2.2.12 to this kernel.
:)
This is important: there was a nasty stack-smashing bug that was fixed late in the pre-releases for this kernel.
It was discovered by ben at valinux dot com, and was posted to BugTraq on Friday.
Ben writes:
While doing some debugging, I discovered a really nasty stack smash
bug in linux-2.2.12. The I haven't checked previous versions of the
2.2 kernel but bug appears to be fixed in linux-2.2.13pre17.
If I am reading this correctly, the implications of this bug could be
very dire. It may be possible to easily obtain root privilege on any
box running this kernel.
Basically the problem is that the execve system call checks that argv
is a valid pointer but it doesn't check that all of the pointers in
argv array are valid pointers. If you pass bad pointers into the
execve system call you can corrupt the processes stack before it
returns to user space. Then when the kernel hands off the process to
the elf loader code and which begins to setup the processes it can be
made to execute some malicious code in place of the program's main
function.
This is particularly scary because all of this occurs BEFORE the
program begins executing its main function and AFTER the program
returns to user space with privilege. Therefore no matter how well
audited the program may be it can be used as to gain privilege.
The thing that tipped me off to the problem was that a program that I
exec'd was getting killed with SIGSEGV in __libc_start_main before my
main function began running.
-ben
There was more discussion that followed, tho I won't summarize it here. But do upgrade
Ouch. I just recompiled 2.2.13, and while the kernel went built cleanly, the new bttv drivers barfed all over my computer. The number of errors was just mortifying. Lots and lots of "dereferencing pointers to incomplete types", implicit declaration warnings, and undeclared variables.
I just used the same makefile from 2.2.12, is there some new weirdness in this kernel? Doh.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
Right from linux-kernel, this seems to have nothing to do with gcc,
a modification in the kernel sources should
do it (it was mentioned in a threat about 2.2.13pre18).
from Matthias Hanisch:
Try to increase the HEAP_SIZE constant to 0x3000 in
linux/arch/i386/boot/compressed/misc.c (as set in current 2.3.x kernels).
I compiled 2.2.13 on a DEC Alpha, threw the vmlinux.gz and System.map to their proper places, rebooted and got the oh-so-fun: "Attempt to access beyond end of device" message from MILO. So it's back to 2.2.12 for me, unless I'm forgetting something. -Tiny P.S. Upgrading kernels on Alphas is much easier than Intel, you don't have to mess with Lilo crap, just replace the kernel and System.map, reboot, and cross your fingers. :)
The best reason to get 2.2.13 is that it is no longer vulnerable to a STACK SMASH bug which effected the previous 2.2.12 and possibly earlier kernels.
Do really dense people warp space more than others?
To be fair, 2.2.13 is intended to be a bit more than just a routine kernel release. There have been important small and not-so-small problems with all of the 2.2.* kernels so far.
2.2.13 is Alan's attempt to make a really bulletproof clean-up of the 2.2.* series so far, and to get it out as a definitive stable reference kernel, before he allows in quite a lot of exciting but more risky new stuff.
2.2.13 is intended as a kernel that distributions should go on including (at least as an option) long after 14,15,16,17 etc are all released and obsolete.
That's why it has taken a lot longer than most releases to go final, and why it is a worthy news item.
Well it's been 2 years and noone's stepped up to make the bttv driver actually work. It deadlocks at framerates between 10 and 24 quite nicely. There was an attempt to rewrite the driver for Video4linux 2 but that guy is in upper division coursework and has more to do besides hacking Linux.
Although not the same problem you seem to be having.
:(
When I moved my one of my boxen with a tv card in it from 2.2.10 to 2.2.12 (didn't have net access between the two), i lost the ability to have both sound and picture at the same time. I could get one or the other, depending on what I passed as argments when insmoding. (I use an ADS Channel Surfer). I mailed ac (as per one of the documentation files about bttv in the kernel), but never heard a response from him. *shrug* I just stayed with 2.2.10.
I believe there was some major re-writing activity going on in the kernel bttv drivers around 2.2.11, 2.2.12, so hopefully they will begin to stabilize with time.
Unfortunatly, I just fried the mb in that box 2 days ago, so I haven't been able to try 2.2.13 on it. It'll be interesting to see how it works out, pending that everything else in that box didn't get fried as well.
This sig is false.
Here is the release notes from Alan:
http://www.linux.org.uk/VERSION/ relnotes.2213.html
Enjoy!
KeepaliveThread::run: device crashed
KeepaliveThread::run: device crashed
KeepaliveThread::run: device crashed
KeepaliveThread::run: device crashed
After only 7 minutes of capturing 640x480 15fps. The biggest joke of all about this driver is that the bug was fixed by an EE student in his video4linux 2 revision and promptly rejected by Linus. At the same time the student created several new bugs which don't exist in the video4linux 1 revision. So we have 2 drivers: 1 which deadlocks at high frame rates and 1 which gives offset fields but doesn't deadlock and with the holidays coming don't expect anything to get fixed.
I saw this in the changelog
SCSI Updates
DVD handling
The DVD handling code has been cleaned up.
Can anyone give me a quick "State of the DVD" update for Linux. Reccommend a drive??
+&x