# Why is there no 2.7 kernel

## norc

Well, in the history there has always been a odd-numbered kernel version, which was the testing version, that the developers 'play' with, and even numbered kernels, that were the ones to use.

But there is no 2.7, so this means the kernel developers are making changes in the 2.6 versions, the versions that most of the linux users use.

Is there a >good< reason for that?

Because I would like to have working kernels exclusively in the portage for example  :Wink: 

I just cant get newer kernel versions, which could be nicer, because of some patches that I just can apply on the 2.6.14 for example, but with them I just get strange problems with some permissions.

----------

## syg00

Linus decided thus - your argument is with him.

I don't like your chances of wining  that argument.

Seems a strange request from a Gentoo user.

The "stable" 2.6 releases are supposed to be just that - although a lot more fluid than the 2.4 series.

If you have problems with what is shipped as stable, hit (kernel) bugzilla.

----------

## frostschutz

http://kerneltrap.org/node/3513

----------

## cp_tar

Well, among oher things, SCO's lawsuit mentions Linux kernel 2.7 IIRC... never was, never will be...  :Wink: 

----------

## norc

IM not whining about anything.

But I dislike the fact having not properly working kernels in the Portage, marked as stable.

And I know the bugzillas, dont worry.

Its just weird IMHO, I dont see any sence in this.

----------

## Pithlit

If it's marked "stable" it means it is stable. Like... rock solid stable. Every "stable" kernel in the portage works properly. If a problem arises (i.e. an exploit is found) all the affected versions promptly go from stable to unstable.

----------

## widan

 *norc wrote:*   

> But I dislike the fact having not properly working kernels in the Portage, marked as stable.

 

There are few problems caused by the kernels, at least if you exclude things like new drivers that just got merged... just give them some time, there's a reason some features are marked experimental.

Also maintaining two kernel trees mean you have to backport new drivers to the "stable" tree regularly (else people will complain that they can't use their new hardware with a stable kernel). That's a lot of work, and kernel developpers don't necessarily want to do that. Sometimes it can get very difficult because of changing APIs, or nearly impossible if the driver depends on new subsystems or changes that only exist in the development tree. So it's not a perfect solution either.

----------

## xanas3712

I've had 0 problems with any of the stable kernels... what are you referring to?

----------

## norc

Xanas3712:

Using the 2.6.14 causes a problem with the permissions on the keymaps while logging in as a user, and that it cant allocate they right keymap.

These look just like warnings, but they seem to cause a lot of bugs in X. Im trying to figure out which especially that are.

This bug has been reported already a few times, but it seems that nobody figured out that the kernel is the evil thingy  :Wink: 

The very weird thingy is, that another guy, with practically the same gentoo, same arch, and with >my< .config from the kernel can build a properly working kernel.

And Ive build the kernel 2 times without any success. (One even in a gentoo new-installation).

I dont know what the kernel has to do with the keymaps, but its definitely the kernel.

Pithlit:

This error causes (random ?) crashes of applications  on X. (Yeeea, im going to report that bug today   :Wink:  )

And thats definitively >not< what I would mark as stable.

widan:

 *Quote:*   

> Also maintaining two kernel trees mean you have to backport new drivers to the "stable" tree regularly (else people will complain that they can't use their new hardware with a stable kernel). That's a lot of work, and kernel developpers don't necessarily want to do that.

 

But thie little extra work helps cleaning the portage from experimental and unstable (I mean unstable literally) kernels, that doesnt fit marked as stable, iE in gentoo, in the portage, if they dont work.

----------

## Paapaa

 *norc wrote:*   

> 
> 
> Using the 2.6.14 causes a problem with the permissions on the keymaps while logging in as a user, and that it cant allocate they right keymap. These look just like warnings, but they seem to cause a lot of bugs in X. Im trying to figure out which especially that are. This bug has been reported already a few times, but it seems that nobody figured out that the kernel is the evil thingy 

 

How did you come to the conclusion that this is a kernel bug?

----------

## enderandrew

In some ways, the 2.6.15 release canidates could be argued as being more stable considering they have numerous bug fixes over the 2.6.14 line.

Older does not mean more stable necessarily.  Just look at the number of fixes that comes with each new version, and you have to wonder why some people stick with considerably older kernels.

New features being added in newer versions can add new bugs, but all I'm saying is that it is not a given that older versions are more stable.

----------

## widan

 *norc wrote:*   

> Using the 2.6.14 causes a problem with the permissions on the keymaps while logging in as a user, and that it cant allocate they right keymap. (...) The very weird thingy is, that another guy, with practically the same gentoo, same arch, and with >my< .config from the kernel can build a properly working kernel.

 

The keymap for the virtual consoles is loaded once during boot (as root), and that's it. And I think that X doesn't rely on the kernel for keymaps, it switches the console to raw mode and handles the mapping itself. Also, the fact that someone else with the same kernel config doesn't have the bug likely means it's not the kernel, but something else in your configuration.

----------

## Pithlit

Ok... at the risk of sounding insensitive or rude... Could you be a little more specific on what kernel you use. Because... (in portage) there is no 2.6.14 vanilla source... and 2.6.14 gentoo source is marked _unstable_.

But aside that... random crashes in X can be caused by a number of things. How did you deduct it's kernel that's causing it?

P.S. I just read your sig. And notice you use an OCed CPU... now I'd bet that has a lot to do with random crashes. If you're troubleshooting stuff, make sure you have a _stable_ system first (everything clocked as it's supposed to), only then you get the right to blame something else.

Of course an OCed CPU might have nothing to do with it, but still... just to be on the safe side.

----------

## norc

Im using the gentoo patched 2.6.13-r5, and have the problems with the 2.6.14-r5.

http://packages.gentoo.org/search/?sstring=gentoo-sources     <-

Sorry, forgot to mention the r5.

How do I deduct its the kernel causing it?

Oh well, when I change the kernel all those problems are >not< happening. Thats weird, isnt it?  :Smile: 

Pithlit: Just for notice, I have this overclocked CPU for a long time, and this setting is stable. Overclocked from a AMD Athlon 1800 to an Athlon 2100. (+215 mhz) (FSB: + 27 mhz). Thats all.  :Smile: 

And I had >never< Problems with that. Not more problems with overclocking it than without oc'ing the CPU.

And -> What about the fact that those problems I have only happen when I have the 2.6.14-r5 (gentoo) kernel?  :Smile: 

Im going to try the other 2.6.14 kernels now, maybe its only the patches that are applied in r5 that cause the crashes.

----------

## afabbro

 *Pithlit wrote:*   

> Because... (in portage) there is no 2.6.14 vanilla source... 

 

<blink, blink>  There's not?

```

hallofjustice vanilla-sources # cd /usr/portage/sys-kernel/vanilla-sources

hallofjustice vanilla-sources # grep KEYWORDS vanilla-sources-2.6.14.2.ebuild

KEYWORDS="alpha amd64 arm ~ia64 ppc ppc64 x86"

hallofjustice vanilla-sources #

```

----------

## Pithlit

Notice the .2 at the end?

----------

## po0f

Getting back on topic, if you bothered to read the mailing list exchange at the link somewhere near the top of the page, you would gather that Morton's -mm kernel is the new development kernel.  When things are proved safe enough there, they are merged with the main kernel.  I read an article in some linux magazine stating that the odd series (2.7) being the development kernel will be stopped.

----------

## Corona688

 *Pithlit wrote:*   

> If it's marked "stable" it means it is stable. Like... rock solid stable.

  Bullshit.  faad2 was broken under amd64 for years and marked stable. All "stable" means is "compiles".  All "unstable" means is "might not compile".

----------

## codergeek42

 *Corona688 wrote:*   

>  *Pithlit wrote:*   If it's marked "stable" it means it is stable. Like... rock solid stable.  Bullshit.  faad2 was broken under amd64 for years and marked stable. All "stable" means is "compiles".  All "unstable" means is "might not compile".

 Incorrect. A package can only be marked stable ('arch') when it has not seen any major bugs for a sufficient time period from being put into the testing branch ('~arch') (security updates notwithstanding). The '~arch' tree generally may also signify that the package works for the developer(s) who tested it, but it still needs to be tested in many other different configurations and environments to be sure of its stability.

If you are having troubles with a package, please file a detailed bug report at Bugzilla. Thanks.

----------

## Corona688

 *codergeek42 wrote:*   

>  *Corona688 wrote:*    *Pithlit wrote:*   If it's marked "stable" it means it is stable. Like... rock solid stable.  Bullshit.  faad2 was broken under amd64 for years and marked stable. All "stable" means is "compiles".  All "unstable" means is "might not compile". Incorrect. A package can only be marked stable ('arch') when it has not seen any major bugs for a sufficient time period from being put into the testing branch ('~arch') (security updates notwithstanding). The '~arch' tree generally may also signify that the package works for the developer(s) who tested it, but it still needs to be tested in many other different configurations and environments to be sure of its stability.

  I'm speaking from experience here, y'know.  I know what stable/unstable is supposed to mean in practice, but that's not what happens.

I'm the one who fixed faad2-2.0-r2 for amd64, which was marked "stable" despite not actually working for amd64 in any shape or form, at all, ever.  It took several bugs and tries to get them to notice -- I figured if they couldn't include the patches, they could at least mark it unstable so as to stop pretending it ever worked...  My patches were eventually included and for a while things were good, only for the patches to be ripped out a few months later when they decided it was better to keep things broken for the sake of legacy, 32-bit-only apps that did things the wrong way.  And yes, faad2-2.0-r2 was still marked stable.  It took several tries to craft a patch that would satisfy their pickiness, which in the end had no real difference from the one I made originally.  Only now that r2 is old enough to have fallen off the portage tree completely, is this broken revision not marked stable anymore.

Is this an exceptional case?  Maybye.  At the very least, though, it demonstrates that a proliferance of bugs and a lack of official testing is no barrier to something getting flagged stable; and once something's marked stable it stays that way, bugs and all.

----------

## codergeek42

Ah. I had not realized that. Thanks for explaining your perspective, Corona688.

----------

## G2k

 *Pithlit wrote:*   

> If it's marked "stable" it means it is stable. Like... rock solid stable. Every "stable" kernel in the portage works properly. If a problem arises (i.e. an exploit is found) all the affected versions promptly go from stable to unstable.

 Bullshit. Kernel versions 2.6.13 and 2.6.14 have problems with hyperthreading whcih have slowed down my machine, I had to revert back to 2.6.12. This has been fixed only in vanilla 2.6.15-rc5.  :Wink:  No computer program is ever really "rock-solid", perhaps just very usable.

----------

## Pithlit

OK... ben bullshited _twice_. Correct me if I'm wrong... isn't amd64 supposed to work in 32bit mode? If the thing works on amd64 (even in 32bit mode) it "might" be considered stable by some people - I wouldn't know... I don't have an amd64 and I don't plan on getting one till _everything_ runs in full 64bit mode. Which imho won't happen for a while. And on HT kernel issue... try reading the changelogs. *Quote:*   

> *gentoo-sources-2.6.14-r5 (15 Dec 2005)
> 
>   15 Dec 2005; Daniel Drake <dsd@gentoo.org>
> 
>   +gentoo-sources-2.6.14-r5.ebuild:
> ...

 It really pays off by reading changelogs on the important packages. They tell youu which bugs have been fixed and subsequently which haven't been. Some might be considered minor bugs (altho not to all of us) as the thing works fine in most situations.

I agree on the "rock-solid" thing tho. As you said... nothing is perfect thus someone must draw the line on when a package is stable and when not. But I think you all know what I meant with "rock solid" (i.e. as good as it gets).   :Wink:  And let's stop with bullshitting eachother...

----------

## Corona688

 *Pithlit wrote:*   

> OK... ben bullshited _twice_. Correct me if I'm wrong... isn't amd64 supposed to work in 32bit mode? If the thing works on amd64 (even in 32bit mode) it "might" be considered stable by some people - I wouldn't know... I don't have an amd64 and I don't plan on getting one till _everything_ runs in full 64bit mode. Which imho won't happen for a while.

  Why get an AMD64, then?  Get a sparc64 or something where you won't have to lie in fear of any of that pesky compatibility -- instead of a path back, you'll be happy to find that unrecompilable 32-bit binaries just plain won't work.  Much nicer.

Less sarcastically, amd64 native 32-bit support is a feature.   :Smile:   You want it.  Trust me.

But no, just 'cause it works under 32-bit mode doesn't mean it'll work when compiled as 64-bit, which is what the amd64 portage flags are supposed to represent except for the emul-linux-x86 packages or binary packages(of which faad2 is neither).  Marking faad2-2.0-r2 stable was basically an admission that whoever flagged it never tested it.

----------

## drescherjm

 *Quote:*   

>  I'm speaking from experience here, y'know. I know what stable/unstable is supposed to mean in practice, but that's not what happens. 

 

I fully agree on that being that I have a lot of amd64 boxes around, I can remember I had to use the ~ package quite a few times to get the package that actually worked. With that said, I can say things are getting much better recently but this tends to be very package dependent.

----------

