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.

Comments

I'm waiting...

[Psiren]

Please feel free to put all the "this isn't worthy news" under this thread. At least that way we can keep things tidy ;)

Re:I'm waiting...

[JPMH]

I really can't wait for the day when a routine linux kernel release doesn't make a slashdot headline.

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.

God bless Alan Cox and Linux Torvalds.

[denmaster]

And just when I thought I'd got the latest pre installed, along comes another one.
Hope the nasties are gone.

Re:God bless Alan Cox and Linux Torvalds.

[GooberToo]

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.

Re:God bless Alan Cox and Linux Torvalds.

[arivanov]

Very very very good point!!!!

Re:God bless Alan Cox and Linux Torvalds.

[nevets]

I totally agree with your point!

But...

There's some of us (I'm included :) 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.

So, please /. 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.

Steven Rostedt

More details soon, I expect

[ajs]

Look to the kernelnotes site for more details. I expect the changes list will appear there first....

Re:More details soon, I expect

[Pa|adin]

Kewl stuff...are there many new changes? I wonder how many releases before the cling-wrapped 2.4 kernels come out? Can't wait.. *jumps up and down*...

Re:More details soon, I expect

[jd]

They've not put an entry for 2.2.13 on either kernelnotes or cuttingedge, as yet. Kernelnotes hasn't even updated the text for 2.2.11 or 2.2.12, so expect a description on cuttingedge before anything appears on kernelnotes.

More info, changelogs

[Mads-Martin]

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.

2.2.13 croaks w/ gcc 2.95.1

[eigenstr]

For me, it dies with "Out of memory" right after decompressing the image. Of course, I'm one of those fools who compiles kernels with gcc 2.95.1. :-)

Re:2.2.13 croaks w/ gcc 2.95.1

[Psiren]

Anyone know if gcc 2.95.1 is better or worse than egcs 1.1.2? I've been compiling my kernels with egcs for quite some time and have yet to come accross a problem, but I'd like to know if 2.95 is more likely to crash and burn.

Re:2.2.13 croaks w/ gcc 2.95.1

[jd]

Did you remember to change the CFLAGS in the Makefile from -O2 to -O6? :)

(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.

Re:2.2.13 croaks w/ gcc 2.95.1

[jd]

I've successfully used 2.95.1 (with PGCC patches) with:

• Linux 2.2.11 + Reiserfs + International Patches + Freeswan patches
• Linux 2.2.12 + Reiserfs + International Patches + Freeswan + PPS + Posix ACL patches
• Linux 2.3.18

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.

Re:2.2.13 croaks w/ gcc 2.95.1

[sdt]

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.

Re:2.2.13 croaks w/ gcc 2.95.1

[ed_the_unready]

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.

---------------------

Re:2.2.13 croaks w/ gcc 2.95.1

[Luyseyal]

well, the compilation died on me too but if you keep re-executing the commandline (make bzImage, or whatever) it'll eventually finish building. i've been running this kernel on a minimal load for several days straight. i'm giving the CFLAGS=-fno-strict-aliasing trick noted above a shot right now. if that's the solution, sounds like their strict-aliasing algorithm has a nasty memory leak in it that makes the compilation crash, but it doesn't seem to generate bad code (well i don't crash on startup anyway. :)

ok, compilation with the new CFLAGS just finished and looks like it worked like a charm. YAY!

-l

Re:2.2.13 croaks w/ gcc 2.95.1

[theMAGE]

Hi!

I'm using RedHat 6.0 with kernel-2.2.12 compiled with gcc-2.95.1.

The only problem I have had is when backing up my Windoze partition with
dd if=/dev/hda1 bs=32M | gzip > windoze.1999xx.gz

I have not reported, as Alan Cox said that if you are using gcc-2.95.x you are on your own :)

Using stock RedHat kernel 2.2.5plx it works just fine.

florin

Re:2.2.13 croaks w/ gcc 2.95.1

[eigenstr]

And indeed, adding that option let the resulting kernel boot. I missed that note...I suppose I deserve what I got for using nearly-bleeding-edge software without reading all the docs. :-)

Re:2.2.13 croaks w/ gcc 2.95.1

[Anonymous Coward]

no it is not a gcc bug, it is a kernel problem. this is from Mr. Cox's homepage www.linux.org.uk/VERSION/relnotes.2213.html -- "This code is intended to build with gcc 2.7.2 and egcs 1.1.2. It is known that not all of it builds validly on the x86 CPU's with gcc 2.95. As far as we know these are Linux not gcc issues. Fixes for gcc 2.95 to gcc 3.0 may go into Linux 2.2 in time. You should therefore not use gcc 2.95 to build stable kernels for the moment." don't expect this to get fixed anytime soon either. the gcc folks and linus often don't get along. read some of the mailing list archives over at sourceware.cygnus.com to see what i mean.

I know this is a stupid question....

[Anonymous Coward]

I just never noticed it before. When did Transmeta own kernel.org? From the beginning, or did they acquire it later? Sorry for asking here, but thee isn't much information from transmeta.com, except for a non-existant typo.

Re:I know this is a stupid question....

[Mads-Martin]

Transmeta have been hosting kernel.org from the beginning.

Re:I know this is a stupid question....

[Anonymous Coward]

Thanx.

.13 voodoo

[Anonymous Coward]

Does any one else here skip any .13 just to keep an old superstiton alive?

Even if 2.2.13 had some horrible FS thrashing bug, alan, linus, & co. could always blame it on .13 a curse.

I think all projects should skip any .13 release purely for the fun of it. (Like old hotels skip the 13th floor). Imagine how bland our culture would be without stupid little superstitions?

Re:.13 voodoo

[Psiren]

Every culture has its unlucky numbers. If we started skipping numbers we'd just have to hava a major release every time, and large gaps. Something like Microsoft ;)

Re:.13 voodoo

[CoderJoe]

A former employer had the development team skip 13 and go right to 14 when numbering versions/pre-releases...

of course, the pre-releases were for the internal qa team to check for bugs before releasing...

Re:.13 voodoo

[Anonymous Coward]

Imagine how bland our culture would be without stupid little superstitions?

Don't we have the superstitious running the government? That's enough for me!

Re:.13 voodoo

[Victor Danilchenko]

I think all projects should skip any .13 release purely for the fun of it. (Like old hotels skip the 13th floor). Imagine how bland our culture would be without stupid little superstitions?

No, no, no! In software industry, '0' is the unlucky number -- most initial (.0 implied) releases are buggy, just look at gcc 2.95(.0)!

--

Re:.13 voodoo

[F.O.Dobbs]

Seems to me 95,98 and especially 2000 are unlucky numbers.

Re:.13 voodoo

[BorgDrone]

I think all projects should skip any .13 release purely for the fun of it. (Like old hotels skip the 13th floor).

Like that guy who was going to bungee jump from an old hotel and in his calculations he forgot there wasn't a 13th floor so he got the cord a little too long....
how is that for bad luck and the number 13. seems like omitting the 13 could be bad luck too!

---

Re:.13 voodoo

[ALG]

The building across the street from where I work not only has a 13th floor, but has TWO of them; 13A and 13B.

ALG

Re:.13 voodoo

[otis wildflower]

Yes, but according to Brooks, aren't odd-numbered releases better than even-numbered releases? ;)

Re:.13 voodoo

[enrayged]

well, Antonio Banderras was the 13th warrior, and he had lots good luck, so 13 was lucky for him... :)

Re:.13 voodoo

[Anonymous Coward]

As far as 'superstitions' go, you should know that kernel 1.2.13 was one of the most stable and long-lived of the 1.2 releases. So much for '13' superstitions.

Re:.13 voodoo

[Anonymous Coward]

Don't be superstitious, it brings bad luck.

Bad luck? ;-)

[Lion-O]

Well, it seems my evening has allready been planned for me. At the moment I'm still running very happily on 2.2.11 but I'm allways curious to see what parts were changed and if there are some new developments going on.

One thing puzzles me though; may I assume that Linux users are by default not supersticious since kernel development now went to number 13 ? ;-)

Re:Bad luck? ;-)

[jd]

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.

Re:Bad luck? ;-)

[josepha48]

I'd upgrade from 2.2.11 to atleast 2.2.12 unless you applied the patch or pathces to 2.2.11. 2.2.11 was known to cause some serious lockups in some systems that required a hard reboot. 2.2.12 is much better AFAIK.

Re:Bad luck? ;-)

[Lion-O]

2.2.11 was known to cause some serious lockups in some systems

Well, just like you said; it depends very much on the sort of machine you're using and the parts of the kernel. 2.2.11 never failed me on my system. Anyway; perhaps I'll notice some improvement once I give 2.2.13 a try.

Re:Bad luck? ;-)

[rmull]

But remember kernel 1.2.13? One of the most stable ever!

Re:Bad luck? ;-)

[BorgDrone]

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 )

---

Re:Bad luck? ;-)

[Anonymous Coward]

Nah - I ran an ISP where the main webserver was running 1.2.13, and it worked like a trooper and was up for nearly a year continuous - I finally rebooted it out of pity.

Re:Bad luck? ;-)

[josepha48]

There was a major tcp/ip mem leak in 2.2.11 that caused my SMP box to lock up solid. Most people who ran 2.2.11 AFAIK id dnot have very long uptimes unlesss they applied the necessary patches.

Mirrors

[Snipes]

"Mads-Martin was one of the many folks to point out that 2.2.13 has made the mirrors. " Let's just hope this kernel doesn't break those mirrors....

question:

[josepha48]

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

Re:question:

[Neon Spiral Injector]

You should always reverse out all your non-standard patches before patching up to the next official release.

Second I always wait a few days after a release to patch up cause I do run a few non-standard patches that aren't available right away.

Third, 13 is my lucky number.

It is known that 2.95 does not work

[Vlad_the_Inhaler]

I am not sure how relevant this is, but the release notes for Kernel 2.2.12 - http://www.uk.linux.org/VERSION/relnotes.2212.html - state:
This code is intended to build with gcc 2.7.2 and egcs 1.1.2. It is known that not all of it builds validly on the x86 CPU's with gcc 2.95. As far as we know these are Linux not gcc issues. Fixes for gcc 2.95 to gcc 3.0 may go into Linux 2.2 in time. You should therefore not use gcc 2.95 to build stable kernels for the moment.

Re:It is known that 2.95 does not work

[jd]

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

old news?

[Cid Highwind]

Is this really new? Mandrake 6.1 came with kernel 2.2.13, So I've been running a kernel that doesn't really exist for 3 weeks now...

[will@darkstar proc]$ cat /proc/version
Linux version 2.2.13-7mdk (root@kenobi.mandrakesoft.com) (gcc version 2.95.1 19990816 (release)) #1 Wed Sep 15 18:02:18 CEST

Re:old news?

[_SkiBum_]

I would say that mandrake probable shipped with one of the 2.2.13-pre kernels, I'm guessing pre7 with a few mandrake patches by the look of your version line.

Re:old news?

[ceeam]

Linux version 2.2.13-7mdk (root@kenobi.mandrakesoft.com) (gcc version 2.95.1 19990816

WOW!!!

Production(?) kernel built with 2.95.1.

Is it "approved" by "big guys" (I mean Alan Cox etc...) now?
Have bugs gone?

Re:old news?

[Anonymous Coward]

You've been running a 2.2.13 prerelease.

Re:old news?

[Anonymous Coward]

It came with a pre .13 kernel.
No kidding:)

Joe Rice
jlrice@columbus.crosswinds.net

Re:old news?

[Anonymous Coward]

..and Mandrake is getting product awards? Explain.

Re:old news?

[timster]

Cox still cautions against using it. As far as I know Linus still uses 2.7.2.3 ;)

Re:old news?

[osu-neko]

What's to explain? They shipped with the latest kernel available at the time.

Are you suggesting they should not have shipped with 2.2.13pre7 and instead shipped with the buggier 2.2.12? Why? You enjoy memory leaks and crashes?

--

Get lost kid...

[Surazal]

Take yer nameless faceless corporation addiction somewhere else, kid. Yer frightening me. :^)

bttv driver fixed?

[yorkie]

I've been having sporadic hangs with the bttv TV card driver for a while, and I noticed that the 2.2.13 pre patches contained a fixed driver, which modifies the interrupt code. I have not installed any of the pre-patches.

I will compile now and see if this fixes my problem, and report back.

Re:bttv driver fixed?

[yorkie]

I've been running the new code for 2 hours, and not had a crash, yet.

The patch adds an extra cli() to the bttv.c code, which appears to fix a part of the driver where interrupts could be disabled and not re-enabled.

No one else using it??

:P Was: Re:help!

[Pa|adin]

I don't know what your problem is, but I bet it's hard to pronounce =)

Re:More details soon (PLEASE?)

[ajs]

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?

You asked for it...

[XNormal]

I really can't wait for the day when a routine linux kernel release doesn't make a slashdot headline. Will I have to wait until linux is obsoleted by another open source project or will it actually happen before that?


----

Re:HELLLLLLOOOO moderators!

[Trojan]

This was not a troll attempt at all. The idea is that inevitably some people will start complaining about kernel release announcements on Slashdot. If those are all posted under one thread, then people not interested in the complaints can just skip that one thread.

SMP back up to snuff?

[Synn]

SMP has been quirky both in the .11 and .12 kernels, anyone know if it's stable in this release?

You really should upgrade

[aheitner]

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

Re:HELLLLLLOOOO moderators!

[Psiren]

Actually, it wasn't a troll attempt. I'm not bothered if Linux kernel version are reported here or not, they always appear on Freshmeat so I won't miss it. It was just a tongue in cheek remark really. Half the people on here want these reports, half don't. Ah well, can't please everyone, least of all AC's with an attitude.

a question of installs

[Anonymous Coward]

my question is, if i've fallen behind and don't have any patches to the 2.2.6 kernal, should i get all the patches up to 2.2.13 or grab a whole new kernal and replace the whole thing.

Major Vomitting Upon Kernel Compile

[Outlyer]

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.

This was in i2c.c

[Outlyer]

whoops, probably should have mentioned that. That and glibc-2.1.2, and pgcc-1.1.3 :)

Jury's still out...

[Anonymous Coward]

That hasn't been settled yet.

Check your hardware if you get signal 11s!

[Spoke]

well, the compilation died on me too but if you keep re-executing the commandline (make bzImage, or whatever) it'll eventually finish building.

If you have to reissue 'make bzImage' commands to finish building the kernel, you most definately have some faulty hardware, most likely bad memory. I bet that you're seeing signal 11's when compiling.

Check the The Signal 11 FAQ for clues on how to debug your problem.

First hint, if you're overclocking, don't!

12 times a day???

[Nicolas MONNET]

I hit reload every 10 minutes. When I'm bored.

Changelog?

[Teferi]

Anyone got a link to a changelog? 2.2.13 hasn't even been announced on kernelnotes, let alone edge, yet.

3.0, yo.

[Anonymous Coward]

Dig on some 3.0 releases sometime... MS-DOS, MS-Windows...

Rollover problem?

[Nicolas MONNET]

Wasn't there a jiffies rollover problem that should have made it freeze before that?
Or was this bug introduced later on?

Re:Rollover problem?

[timster]

IIRC the jiffies rollover doesn't usually cause a freeze. I think it's also more than a year.

Solution to this problem

[platypus]

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

Re:Solution to this problem

[law]

Thank you this fixed my problem!
I read the same email, but thought somehow it only applied to 2.3.x kernels.

Re:IS THIS NEWS FOR NYRDS?

[Type-R]

AND IMPLEMENTATION DETAILS OF OPERATING SYSTEMS.

Hmmm, if the kernel isn't an implementation detail of an operating system, what is.

True.

[aheitner]

But in my book it's out there enough to merit attention, especially since there's some indication that this was not a problem in 2.0.36.

2.2.13 on Alpha won't boot

[AGTiny]

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

kppp and latest kernel

[Anonymous Coward]

For some strange reason when I run kppp with the new kernel, kppp says no PPP is installed in the kernel or as a module, yet I have the slhc and ppp modules installed, if I ignore the error message and continue on, kppp will dial and connect properly. I have upgraded to the latest version of kppp and pppd yet I still get this error. Would this have anything to do with compiling with gcc 2.95.1?? Anyone else getting these errors?

Re:kppp and latest kernel

[Anonymous Coward]

I'm getting the same thing with 2.2.13pre18 and sound modules -- not that ppp is working well since the 6.1 upgrade. Try running sndconfig & tell me if you can get to the second screen.

So far, I get the message "soundcore.o ... not in your module path" even though lsmod, rmmod, and insmod all work on soundcore.o just fine. Really annoying!

Re:kppp and latest kernel

[Malarre]

I'm also getting the same error. I compiled with egcs-1.1.2 so it's not a gcc 2.95 related issue as far as I can tell. A simple workaround I'm using is to just start up pppd manually, kill it, and re-dial out, then everything works.

ChangeLog (kinda)

[hawkfan]

For those who want to know what might have been changed, Alan Cox posted the announcement for 2.2.13pre18 with a changelog.
His diary says he sent it to Linus for the official ok.

Re:More details soon (PLEASE?)

[mwillis]

Try reading the pre series announcements. This is at linuxtoday:

2.2.13pre18 released

Odds are that the official release will be pretty close.

Exploit for 2.2.12

[D3]

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.

Re:help!

[timster]

Pretty good there, much better than the sort of "first post" crap that normally gets the -1 honor. Very nice.

No solution to bttv lockups

[heroine]

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.

I've had problems with bttv drivers as well. :(

[Dast]

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

Here is the REAL release notes!

[Lface]

Here is the release notes from Alan:
http://www.linux.org.uk/VERSION/ relnotes.2213.html

Enjoy!

USB Mice?

[Anonymous Coward]

Does this version support USB mice natively, and if not, does anyone know of resources for using USB mice in Linux/FreeBSD? I really want a USB Intellimouse Pro to help with my quaking.

-W.W.

No.

[heroine]

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.

Re:No.

[icepick]

Umm... How hard could it be too fix? Or at least try?
--

Re:More details soon (PLEASE?)

[Pa|adin]

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.

I doubt that's the situation. I'd just be patient and wait for the notes to be released =) In the USA anyway, it was released quite late in the nite (from when I got the gist of it anyway...

This is a bug in kppp

[Krischi]

The way kppp tested whether the kernel supports PPP, unwittingly took advantage of a security hole that was fixed in the kernel versions 2.2.13 and 2.3.x. See Bug 2164 on the KDE web site. Nothing serious.
According to the bug report, you can simply ignore the error message or remove the test for the ppp0 device from the kppp source code.

2.2.13 release notes

[Anonymous Coward]

I know that the link was pointed out before.

But I think that people reading the 2.2.13 thread
here should find out directly about the 2.2.13 new/uptedated stuff.

So here we go:

Linux 2.2.13 Release Notes

Platforms:Alpha (see notes), PowerPC, Sparc, X86

Introduction
Linux 2.2.13 is the latest update to the Linux kernel tree. It fixes the memory leak bug in the 2.2.11 kernel. In addition it updates various drivers
and the platform specific support. The out of the box tree supports the Alpha, PPC, Sparc and X86 platforms. MIPS is mostly merged but you
should obtain the platform specific tree. ARM and M680x0 users should get their platform specific tree.

Errata

Compilers
This code is intended to build with gcc 2.7.2 and egcs 1.1.2. It is known that not all of it builds validly on the x86 CPU's with gcc 2.95. As far
as we know these are Linux not gcc issues. Fixes for gcc 2.95 to gcc 3.0 may go into Linux 2.2 in time. You should therefore not use gcc 2.95
to build stable kernels for the moment.

Binary Compatibility
Linux 2.2.13 changes a few internal system structures. You may need to rebuild a few third party modules such as pcmcia-cs when upgrading
from older kernels to this one.

Security Notes
2.2.13 fixes numerous small security issues. Most of these were not publically known and exploited. Nevertheless anyone with untrusted local
users should upgrade. Other users are recommended to upgrade.

Architecture Updates

Alpha

i386
The APM code works around a Thinkpad BIOS error reporting bug.
The EBDA BIOS pointer is now honoured if it appears sane. This should fix problems with some large SMP boxes.
A TLB handling race on SMP boxes has been fixed.
The APIC support has been updated.
Workarounds have been added for audio bugs in the MediaGX CPU.
Workarounds have been added for an ISA DMA hang on the VIA Apollo Pro.

MIPS

PowerPC
A collection of PowerPC updates have been merged with the main tree.

Sparc
A bug in the locking of the video card drivers on SMP boxes has been fixed.
General updates and merges of Sparc fixes into the main tree.

Core Updates

A.out loader
Bugs have been fixed in the ZMAGIC loader code.
Bad PCI cards
A PCI card with faulty configuration entries for the devsel could cause a crash when the /proc/pci file was viewed.
Boot up
On some boots machines with very large numbers of processors may not successfully boot all processors. This is now fixed.
Bottom Half Locking
An SMP race in the bottom half handling has been fixed.
Buffer Leak
A buffer leak has been fixed.
Console logging
A race with klogd and the console has been fixed.
Optimisations
The ISA DMA handling in the memory allocator has been optimised.
PCI
Fixes have been made to the PCI multi-function handling.
Shared IRQ's
A shared IRQ handling bug was fixed.
Signal queue corruption
A bug in the real time signal queue handling has been fixed.
Task counting
An SMP task counting race has been fixed.
VM cache handling
A bug where mmap data might not get written back has been fixed.
Xntp
The NTP code has SMP locking fixes.

Driver Updates

BTTV TV card
ADS data update. Fixed schedule in interrupt crash. Updated tuners.
CD-ROM drivers
The CD-ROM drivers have been updated.
C-Media CM8338
A vendor supplied driver has been added.
Console
TIOCCONS tests have been updated.
Cyclades
The cyclades driver has been updated.
EEpro100
The EEpro100 card could lock up on configuration if it shared an IRQ.
EEpro100
The EEpro100 driver now supports the Ultrasparc.
IDE on SMP boxes
The IDE code has been updated to fix several hangs on SMP machines, especially when the machine has the IDE IRQ shared.
ESS Solo
The ESS solo claimed extra I/O resources.
ISDN
The ISDN layer and drivers have been updated.
MSP 3400
The MSP3400 driver for the sound decoders on some TV cards has been updated.
Multisound
The Multisound drivers have been updated.
Neomagic Audio
An audio driver for the Neomagic 256 has been added.
PCWD
The PCWD Watchdog driver has been updated.
SB1000 Cable Modem
Documentation has been updated.
Serial
The 16450/16550 driver didn't correctly reset the FIFO settings on a manually requested chip change.
Memory leaks fixed.
Sound
The core sound code has been updated to handle the ARM.
SoundPro
The documentation has been improved.
SX Serial driver
Small fixes have been made.
Synclink
The synclink driver has been updated
Trust radio card
This is now supported.
VIA 82Cxxx audio
The VIA 82Cxx audio is now supported.

File System Updates

Amiga RDSK
The Amiga partitioning code has been fixed to remove a leak.
Ctime
The ctime of a file is updated on a rename.
Ext2 flags
The ext2 attribute flags could be mishandled.
ISOfs
A small bug in the ISOfs handling has been sorted.
Procfs
The procfs allowed some files to be opened by incorrect names.
QNXfs
Memory corruption in the QNX code has been fixed.
Quota
Small quota bugs were fixed.

Miscellaneous Updates

Message formatting
A couple of message formatting errors/typos have been cured.
Poll
Some internal code tidyup has been done.

Network Updates

1 Second Delay
A bug in the traffic scheduling that could cause 1 second delays in packet transmission is fixed.
3c527
This driver now should work in a multicast environments.
3c529
A confusing message on load has been fixed.
3c59x/3c90x
The driver recognizes some of the newer cards.
64bit cleanness
The 8390, ne2k-pci and rtl8139 drivers have been updated to be 64bit clean.
Amateur radio
Several amateur radio protocol updates.
Arcnet
A crash in the arcnet driver has been fixed.
ATP Ethernet
The delay loops in this driver were faulty and have been fixed.
Davicom DM9102
A vendor provided driver has been added.
Defragment
The always defragment feature is now run time configured.
EEpro
The EEPro driver supports multiple cards now.
IPX
A bug in the IPX packet forwarding for netbios flood fill has been fixed.
Masquerade
Fixes have been made in the masquerade list and memory handling.
Networking
Assorted small fixes have been made.
NFS Logging
A collection of debugging log messages have been removed.
SiS 900 driver
The SiS900 driver had a compile bug in some situations.
SMC Ultra
An oops on module unloading has been fixed.
Thunderlan
Thunderlan now unloads if it finds no cards. It also takes module parameters.

SCSI Updates

Acard ATP870-U
This driver had problems with earlier 2.2 kernels. It should now be stable both compiled-in and as a module.
Advansys SCSI
The Advansys scsi driver has been updated.
DVD handling
The DVD handling code has been cleaned up.
EATA SCSI
The EATA SCSI driver has been updated and now supports Alpha
IBM ServeRAID
An IBM contributed driver is now included.
NCR 5380
A problem parsing command line options when the NCR5380 is compiled in has been resolved.
NCR 53c710
A driver has been added for generic NCR53c710 devices.
Qlogic FC
The Qlogic fibrechannel driver has been updated.
Qlogic ISP
Updates and bug fixes.
Scsi Generic
Documentation updated.
Symbios 1510D
The Symbios driver now supports this code.

Security Updates

Chown
Chown now clears the setuid bit.
Clone
The CLONE_PID flag is no longer available except to the kernel.
Exec
A denial of service attack in the execve() code has been fixed, as well as a potential case where a corrupt argument set could be
passed to the process being executed.
Mknod
Mknod no longer follows symbolic links.
Rate limiting error logs
The a.out and Sunrpc layers now limit their error logging rate.
Procfs
The stack pointer is not visible to other processes when it might provide useful info to an attacker.
Shared memory
The amount of shared memory allocatable is now configurable.
Signal handling
Sending non standard process exit signals is now restricted to thread groups.
TCP Sequence Guessing
A bug allowing TCP sequence guessing has been fixed.
TTY Locking
A tty locking bug that could allow denial of service attacks.

DVD Question?

[Wah]

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??

The History of 13

[Anonymous Coward]

In many cultures 13 was/is actually considered a good luck number. Especially with religions that had holidays based on the moon cycle (13 moons in a year). In Europe durring the middle ages the dominate culture started trying to exterminate all other cultures. Turning 13 from good luck to bad luck was just a small part of the propaganda. And that is why 13 is bad luck in Western culture.

(Why do I now have a craving for Yogurt all of a sudden?)

Do I need to unpatch a pre kernel first?

[Anonymous Coward]

I'm running Mandrake 6.1 which installed a prelease of 2.2.13 (2.2.13-7mdk). Do I need to unpatch this before applying the new release 2.2.13 patch?

I tried patching what I have (after backing up the source tree first, of course) and had one hunk fail, plus I got a bunch of those "previously applied patch detected: Assume -R?" messages.

thanx

Too much data!!!

[Ricardo Casals]

So, what are we gunna see now? Postings of how each bit of each kernel is doing?...

Oct 21, 1999: We're done with 10% of 2.3.23
Oct 22, 1999: We're done with 19% of 2.3.23
Oct 23, 1999: We're done with 43% of 2.3.23
Oct 24, 1999: We're done with 69% of 2.3.23
Oct 25, 1999: We're done with 85% of 2.3.23
Oct 25, 1999: We're done with 99% of 2.3.23
Oct 26, 1999: We're done with 2.3.23 ... woo!
Oct 26, 1999: We released 2.3.23 and since it was still buggy, we're working on 2.3.24...

Oct 27, 1999: We're done with 11% of 2.3.24
etc, etc, etc...

OK OK OK!!! Hooray! We're getting more kernels! But do we have to see EACH AND EVERY LITTLE ONE publicised like its a whole new world every minor patch!!!! AGGGGHH!!
I'm done.

Re:IS THIS NEWS FOR NYRDS?

[Anonymous Coward]

Yep. The kernel is.

So, let's talk about what's new and exciting in the new Kernel. What new 1980's-era features have finally made their way into the kernel this week?

-fno-strict-aliasing

[peter]

The linux/Makefile has code to check if your
compiler accepted -fno-strict-aliasing, and
included it in CFLAGS if so. It has been doing
this since 2.2.11 (or earlier, I don't know when
the first kernel to do this was).

This should mean that it will be included without you having to do anything. You can tell whether it worked or not by looking at make's output, to see what it says it's passing to gcc.
#define X(x,y) x##y